dynamo论文报告.ppt

* * Dynamo的关键设计要求之一是必须增量可扩展性。 这就需要一个机制来将数据动态划分到系统中的节点(即存储主机)上去 * * 前面讲过，通过?hash?然后求余的方法带来的最大问题就在于不能满足单调性，当?cache?有所变动时，cache?会失效，进而对后台服务器造成巨大的冲击，现在就来分析分析?consistent hashing?算法。 移除，仅改变object4 添加，仅改变object2 * hash?算法并不是保证绝对的平衡，如果?cache?较少的话，对象并不能被均匀的映射到?cache?上 使用虚拟节点后：因此对象?object1?和?object2?都被 采用虚拟节点的好处： 1、如果一个节点不可用(由于故障或日常维护)，这个节点处理的负载将均匀地分散在剩余的可用节点。 2、当一个节点再次可用，或一个新的节点添加到系统中，新的可用节点接受来自其他可用的每个节点的负载量大致相当。 3、一个节点负责的虚拟节点的数目可以根据其处理能力来决定，顾及到物理基础设施的异质性。 映射到了?cache A?上，而?object3?和?object4?映射到了?cache C?上；平衡性有了很大提高。 * 具体的过程以下面这个图为例： 一个对象的key为k,其位置在这，那么nodeB负责该对象的读写，这个nodeB就成为coordinator(协调器)。 * 熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的必威体育精装版值。 * * * * 现在有个手机商城，里面卖的iphone价格是瞬息万变的，有全国各地好几个编辑不停地更新自己那边iphone的价格。当然同时也不断有用户询问当前iphone的价格。 假设该商城有A、B、C三个node，则我们的N是3。 我们准备只写一份W=1,那么根据W+RN有R=3。那么就有如下场景： 首先A收到了iphone价格是4000的请求。我们有了4000[A:1]; 在数据被复制到B，C之前，有人告诉A，价格上调，变成了4500.那么A上就有了4500[A:2],它覆盖了之前的[A:1] 随后这个价格被复制到了B，C。那么B，C上也有了4500[A:2]. 此时，有人告诉B说iphone又涨了，变成了5000块，那么B上就有了5000[A:2,B:1] 在B上这个价格被复制到A，C之前，又有个请求到C说iphone降价了，变成了3000块！ 经过上面这么一番折腾，C上有了3000[A:2,C:1],此时A上是4500[A:2]， B上则是5000[A:2,B:1]。 三个node上数据全不一致！！！有点儿乱啊~ 根据墨菲定律——最不想发生的事情发生了——这时有人询问iphone的价格。 看看vector clock这时能起到什么作用？ 由于我们的R=3, 所以这三个几点上的数据都会被读到，那么4500、5000和3000哪个被返回呢？显而易见，A上的版本最低，应被舍弃，那么B和C呢？ 客户端拿到3000[A:2,C:1]和5000[A:2,B:1]确实有点手足无措，但我们可以让它有个判断依据——比如时间戳——现在客户端看到B上的数据是必威体育精装版的，那么结论就是5000. 既 然已经有了结论，那就不能让之后的客户端再这么纠结，接下来就是要统一各个节点，合并vector clock。这时候要做的事情就是通知A节点，现在iphone价格是5000以及得到5000这个值所基于的vector clock.这样A上的数据就变成了5000[A:3,C:1, B:1]. 这样，再有读请求的话，我们可以毫不犹豫的选择A上的数据。 我们看看如果W=2,R=2的情况： A收到4000，但是只有这个数据也到达B，才算成功。所以我们有了A上的4000[A:1]和B上的4000[A:1] 在被复制到C之前，有人告诉A，价格上调，变成了4500.同上A和B上都会有4500[A:2] 数据被复制到C，C上也有了4500[A:2] 此时，有人告诉B说iphone又涨了，变成了5000块，那么B上就有了5000[A:2,B:1] 同1理，C上有了5000[A:2,B:1] 又 有个请求到C说iphone降价了，变成了3000块！那么C上应该有3000[A:2,B:1,C:1] .同1理，新数据的写也会到达A,A上的4500[A:2]看到3000[A:2,B:1,C:1]后，无条件接受被覆盖，因此也变成了 3000[A:2,B:1,C:1]。 经过上面这么一番折腾，C上有了3000[A:2,B:1,C:1],此时A上是3000[A:2,B:1,C:1]， B上则是5000[A:2,B:1]。 这