背景
为什么需要复制数据？ - 允许系统在部分节点出现故障后继续工作（增加可用性） - 地理上保持数据离用户更近（减少延迟） - 扩展可以提供查询的机器数量（增加读吞吐）
复制算法： 1. 单主复制：所有客户端都将写入操作发送到主节点上，该节点负责将数据更改事件发送到其它副本。每个副本都可以接受读请求，但内容可能是过期值。 2. 多主复制：系统中存在多个主节点，每个都可以接受请求，客户端将写请求发送到其中一个主节点上，该节点负责将数据更改事件同步到其它主节点和自己的从节点。 3. 无主复制：客户端将写请求发送多个节点上，读取时从多个节点上并行读取，以此检测和纠正某些过期数据。
主从复制可参考 link
Amazon已放弃Dynamo，因此无主复制，不是一个好思路。
无主复制
单主、多主复制思路都是：客户端向一个主节点发写请求，而DB系统负责将写请求复制到其他副本。主节点决定写顺序，从节点按相同顺序应用主节点发送的写日志。
某些数据存储系统采用不同设计：放弃主节点，允许任何副本直接接受客户端的写。最早的复制数据系统就是无主节点的（或称之为去中心复制、无中心复制），但后来在关系数据库主导时代，这个想法几乎被忘却。在亚马逊将其用于其内部的Dynamo系统后，它再一次成为流行的DB架构。 Riak，Cassandra和Voldemort都是由Dynamo启发的无主复制模型的开源数据存储，所以这类数据库也被称为Dynamo风格。
在一些无主实现中，客户端直接将写请求发到多副本，而另一些实现中，有一个协调者（coordinator）节点代表客户端进行写入，但与主节点的数据库不同，协调者不负责维护写入顺序。这种设计差异对DB使用方式有深远影响。
失效节点重新上线，而客户端开始读取它。节点失效期间发生的任何写入在该节点都尚未同步，因此读取可能得到过期数据。
为解决该问题，当一个客户端从DB读数据时，它不是向1个副本发送请求，而是并行发送到多副本。客户端可能会从不同节点获得不同响应，即来自一个节点的最新值和来自另一个节点的旧值。可利用版本号确定哪个值更新。
读修复和反熵
复制模型应确保所有数据最终复制到所有副本。在一个失效节点重新上线后，它如何赶上错过的写入呢？
Dynamo风格的数据存储系统常机制：
读修复（Read repair）
当客户端并行读取多副本时，可检测到过期的返回值。客户端可判断副本3是过期值，然后将新值写入该副本。适用于读密集场景
反熵过程（Anti-entropy process）
一些数据存储有后台进程，不断查找副本之间的数据差异，将任何缺少的数据从一个副本复制到另一个副本。和基于主节点复制的复制日志不同，此反熵过程不保证任何特定的顺序复制写入，并且会引入明显的同步滞后
并非所有系统都实现这俩方案。如Voldemort目前无反熵过程。若无反熵过程，由于【读修复】只在发生读取时才可能执行修复，那些很少访问的数据有可能在某些副本中已丢失而无法再检测到，从而降低了写的持久性。
反熵就是树形的hash，用于快速比较数据是否一致的。