单、多主复制的思路都是：客户端向某主节点发写请求，而DB系统负责将写请求复制到其他副本。
主节点决定写顺序
从节点按相同顺序应用主节点发送的写日志
某些数据存储系统另辟蹊径：放弃主节点，允许副本直接接受客户端写。最早的复制数据系统就是无主节点（或称之为去中心复制、无中心复制），但后来在关系DB主导的时代，这想法被忘却。在亚马逊将其用于其内部的Dynamo系统1后，它再一次成为流行的DB架构。Riak，Cassandra和Voldemort都是由Dynamo启发的无主复制模型的开源数据存储，所以这类DB也被称为Dynamo风格。
某些无主实现，客户端直接将写请求发到多副本
而另一些实现中，有个协调者（coordinator）节点代表客户端进行写入，但与主节点的DB不同，协调者不负责维护写入顺序
4.1 节点故障时写DB
假设三副本DB，其中一个副本当前不可用（或许正在重启以安装系统更新）：
主节点复制模型下，若要继续处理写，则需执行故障切换
而无主模型，则不存在这切换
图-10：User 1234将写请求并行发送到三副本，两可用副本接受写，而那不可用副本无法处理。假设这俩成功确认写，User 1234收到两个确定响应后，即可认为写成功。完全能忽略那一个副本无法写入的情况。
等失效节点重新上线，而客户端开始读取它。节点失效期间发生的任何写入在该节点都尚未同步，因此可能读到过期数据。
为解决该问题，当某客户端从DB读数据时，它不是向1个副本发送请求，而是并行发送到多个副本。客户端可能会从不同节点获得不同响应，即来自一个节点的最新值和来自另一个节点的旧值。可利用版本号确定哪个值是更新的。
Dynamo不适用于Amazon以外用户。 令人困惑的是，AWS提供了一个名为DynamoDB的托管数据库产品，它使用了完全不同的体系结构：它基于单领导者复制。 ↩︎
