测试PostgreSQL、Redis、MongoDB以及Riak的分区容忍性

jieforest

但是，即使选择能够确认数据已经成功地提交到主节点的WriteConcern.SAFE级别，它仍然会丢失大量的写操作：

1. 6000 total
   
2. 5900 acknowledged
   
3. 3692 survivors
   
4. 2208 acknowledged writes lost! (╯°□°）╯︵ ┻━┻
   
5. 458 463 468 473 478 483 ... 3075 3080 3085 3090 3095 3100 0.98333335 ack rate
   
6. 0.3742373 loss rate
   
7. 0.0 unacknowledged but successful rate
   

复制代码

由于分发协议是异步的，写操作会持续地在n1上操作成功，即使n1无法将这些写操作分发给集群中的其它节点。当n3稍后被选为主节点时，它的数据已经不是最新的数据了，因为它和n1的各种写操作没有进行对接。这两个节点会不一致地并存一段时间，直到n1意识到它必须降级为止。

jieforest

当分区情况恢复后，Mongo会尝试判断哪个节点拥有权威性，很显然，没有一个权威节点的存在，因为两个节点在分区时都接受了写操作。随后，MongoDB会尝试寻找拥有最高optime（每个节点的oplog的时间戳）的节点，然后它迫使旧的主节点（n1）回滚到最近的一次数据相同的时间点，随后重新应用在n3上发生的各种操作。

在回滚过程中，MongoDB会将冲突对象的当前状态的快照写入磁盘上的一个BSON文件中，某个操作者可以在稍后尝试重建文档的适合状态。

这个系统存在着多个问题。首先，在选择主节点的代码中有个缺陷：MongoDB可能会将分发集中某个并没有最高的optime的节点升级为主节点。其次，在回滚的代码中也有个缺陷。在我的测试中，回滚大约只有10%的次数是成功的。在大多数情况下，MongoDB会完全丢弃冲突数据。此外：在回滚过程中并非所有的对象类型都会被完整地记录下来：例如按照设计，超过上限的集合就会丢弃所有的冲突。第三，即使系统运行正常，回滚日志也不足以恢复线性一致性。由于回滚的版本与oplog并没有共享一个定义良好的因果次序，因此通常只有无次序的合并操作（例如CRDT）才能重建文档的正确状态。

线性一致性的缺失也同样发生在FSYNC_SAFE、JOURNAL_SAFE、甚至是REPLICAS_SAFE等级别中，虽然它们能够确保在请求成功之前已经有两个从节点确认了本次写操作。

1. 6000 total
   
2. 5695 acknowledged
   
3. 3768 survivors
   
4. 1927 acknowledged writes lost! (╯°□°）╯︵ ┻━┻
   
5. 712 717 722 727 732 737 ... 2794 2799 2804 2809 2814 2819
   
6. 0.94916666 ack rate
   
7. 0.338367 loss rate
   
8. 0.0 unacknowledged but successful rate
   

复制代码

jieforest

在MongoDB的模型中恢复线性一致性的唯一方法就是等待某一数量的仲裁节点返回响应。但是WriteConcern.MAJORITY级别依然不是一致的，它会丢失已确认的写操作并恢复已失败的写操作。

1. 6000 total
   
2. 5700 acknowledged
   
3. 5701 survivors
   
4. 2 acknowledged writes lost! (╯°□°）╯︵ ┻━┻
   
5. (596 598)
   
6. 3 unacknowledged writes found! ヽ(′ー｀)ノ
   
7. (  562 653 3818)
   
8. 0.95 ack rate
   
9. 1.754386E-4 loss rate
   
10. 5.2631577E-4 unacknowledged but successful rate
    

复制代码

jieforest

UNSAFE、SAFE以及REPLICAS_SAFE等级别在分区时会丢失任意数量或全部写操作，而MAJORITY级别只会在分区开始时丢失未完成的写操作。当主节点降级时它会为所有WriteConcern请求签名，将每个回复的OK设为TRUE，无论WriteConcern是否已被满足。

此外，MongoDB会产生任意数量的漏报（false negative）。在本次尝试中，有3个未被确认的写操作实际上已经在最后的数据集中恢复了。至少到2.4.1版本为止，无论在哪一个一致性级别上，都没有办法在分区时防止数据丢失。

如果你需要MongoDB实现线性一致性，请使用WriteConcern.MAJORITY级别。它不会带来真正的一致性，但至少大量减少了写操作的丢失。

jieforest

Riak

作为Dynamo的一个克隆项目，Riak对分区容忍采取了AP方式，它能够检查到因故产生分歧的历史数据，无论是由于分区还是普通的并发写操作，并且将某个对象的所有有分歧的拷贝都展现给客户端，由客户端决定如何合并这些冲突。

Riak中的默认合并功能是后来者获胜的方式。每个写操作都包含一个时间戳，合并时只保留时间戳最大的版本。如果各节点的时钟是完全同步的，那么该方式能够确保Riak始终使用最近的数据。

即使没有分区及时钟不同步的情况，并发写操作也意味着后来者获胜的策略会导致成功的写操作被默默地忽略掉：

1. 2000 total
   
2. 2000 acknowledged
   
3. 566 survivors
   
4. 1434 acknowledged writes lost! (╯°□°）╯︵ ┻━┻
   
5. 1 2 3 4 6 8 ... 1990 1991 1992 1995 1996 1997
   
6. 1.0 ack rate
   
7. 0.717 loss rate
   

复制代码