dynamo 读书笔记

亚马逊 dynamo的解决的问题：
可用性、一致性、成本效益和性能。主要完成对业务状态的管理。
途径是去中心化，即去掉一个中心节点导致的单点故障或者影响服务质量的情况。
主要确保数据永远可写、高可用性两点。

dynamo的特性：

1. 数据划分
2. 一致性哈希
3. 对象版本
4. 去中心化技术
5. 分布式故障监测（gossip）

对于ACID，dynamo只提供高A，弱C，不提供I的特性。

SLA（服务水平协议）：
在并发达到500次/秒的时候，99.9以上的请求在300ms之内。

设计原则：

1. 永远可写：为了确保系统的可用性，在数据不一致的时候牺牲一定的一致性，保证数据永远可写。采用对象版本的方式来达到最终一致性；
2. 协调冲突：最后一次写入获胜；
3. 增量的可扩展性：能够一次扩展一个节点；
4. 对称性：每个节点都存在对称节点，对称节点之间具有相同的责任；
5. 去中心化：没有中心的节点，完成不可替代的功能；
6. 异质性：所有的节点不是一样的，可以允许加入一台不同的机器。

P2P的系统：
Freenet
Gnutella
Pastry
Chord
Oceanstore
PAST
主要解决数据存储和分配的问题，还有相应的资源发现等问题。dynamo采用的是O(1)的DHT方式来解决问题。

问题和技术方案：

问题	技术	优势
划分	一致性哈希	增量的可伸缩性
写入的高可用性	矢量时钟 读取过程中的协调
暂时性的失败处理	草率仲裁（sloppy quorum）并暗示移交（hinted handoff）	高可用性和耐用性
故障恢复	merkle树的反熵	在后台同步不同的副本，迅速发现
故障监测	gossip的监测协议	保持对称性，并避免中心节点

一致性哈希：
当一个节点不可用的时候，其负载会均匀的分散到其它节点上；
当节点再次可用，节点接受到的负载与其它节点的负载大体相同；
一个物理节点的逻辑负载可以根据逻辑节点的情况来做动态调整。

数据复制：
有一个协调员节点负责把数据复制到后续的n个物理节点去，保证数据的分布性。

矢量时钟：
采用一个向量组保存版本信息，向量组中主要包含了（修改节点，版本号）这样的向量。这样在数据产生冲突的时候可以方便的合并。

读写冲突协调：
读操作中，协调员读取所有N个节点的数据，如果有冲突则进行合并，并把合并以后的节点写回到系统中的N个节点去。
写操作中，协调员把操作写到本地，然后同步到N个节点去。
读写操作中有两个配置项，R和W，分别表示一次成功的读取和写入需要参与的节点数，如果一次写操作中，同步的N个节点有W-1个返回了成功，则表明当前的这次写操作是成功的。读操作也是一样的。如果W+R > N则表示这个系统是最终一致的，即无论一次写操作是否同步到所有的节点，经过一段时间的读取和写入后，所有节点上的数据可以保持一致。

暗示移交（Hinted handoff）：
当系统中有一个节点出现故障的时候，原来写入的N个节点将顺延，这样就有一个原本不该写入某个数据的节点写入了这个数据，因此，系统会定时扫描，故障节点是否已经恢复，如果节点已经恢复，则备份的节点会同步数据到故障节点，并且删除自己临时保存的数据。

数据同步：
使用了MerkleTree，这是一种哈希树，其叶子是各个key的哈希值，父节点的值为其子节点的哈希值。这样，当同步大量key的时候，只需要从树根开始遍历树即可，减少了比较的次数。很适用于大量数据中只有少量数据需要同步的情况。

R、W、N可调整，其中N决定了数据的耐久性，即在节点故障的情况下数据保持可用的能力；RW决定了系统的可用性、耐用性和一致性。

转载于:https://www.cnblogs.com/magiczhao/archive/2012/04/09/2438744.html