dynamo 读书笔记
亚马逊 dynamo的解决的问题：
可用性、一致性、成本效益和性能。主要完成对业务状态的管理。
途径是去中心化，即去掉一个中心节点导致的单点故障或者影响服务质量的情况。
主要确保数据永远可写、高可用性两点。
dynamo的特性：
- 数据划分
- 一致性哈希
- 对象版本
- 去中心化技术
- 分布式故障监测（gossip）
对于ACID，dynamo只提供高A，弱C，不提供I的特性。
SLA（服务水平协议）：
在并发达到500次/秒的时候，99.9以上的请求在300ms之内。
设计原则：
- 永远可写：为了确保系统的可用性，在数据不一致的时候牺牲一定的一致性，保证数据永远可写。采用对象版本的方式来达到最终一致性；
- 协调冲突：最后一次写入获胜；
- 增量的可扩展性：能够一次扩展一个节点；
- 对称性：每个节点都存在对称节点，对称节点之间具有相同的责任；
- 去中心化：没有中心的节点，完成不可替代的功能；
- 异质性：所有的节点不是一样的，可以允许加入一台不同的机器。
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决定了系统的可用性、耐用性和一致性。
