NoSQL－Quorums－仲裁

作者简介：

当你权衡“一致性”或“持久性”的时候，不是一个非此即彼，非黑即白的过程。一个请求中涉及的节点越多，那么我们越有可能避免不一致。这自然就引发了一个问题：需要多少个节点才能保证强一致性？

5.5. Quorums 仲裁

当你权衡“一致性”或“持久性”的时候，不是一个非此即彼，非黑即白的过程。一个请求中涉及的节点越多，那么我们越有可能避免不一致。这自然就引发了一个问题：需要多少个节点才能保证强一致性？

现在假设一份数据需要复制到三个节点中。你不需要所有的节点都确认写入操作来保证强一致性，你只需要其中的两个节点确认了写入操作就可以了，也就是大多数。如果出现冲突的写入，只需要得到大多数的认可（也就是超过半数）。这个做法我们称作“写入仲裁”（write quorum），我们也可以用一个稍微做作的不等式来表示就是：W > N/2，什么意思呢？就是参与到写入操作的节点数量必须要多于涉及到复制的节点数量（N）的一半。副本（replicas）的数量通常又被称作“复制因子”（replication factor）。

与写入仲裁（write quorum）相似的是读取仲裁（read quorum）的概念：就是你和多少个节点联系确保了你能获得最新的数据。读取仲裁更复杂一点，因为这依赖于多少个节点需要确认一个写入。

现在我们就分析下复制因子为3的情况。如果所有的写入需要两个节点来确认(W = 2) ，那么我们需要联系至少两个节点来确保我们能获得最新的数据。但，如果，写入只是被一个节点确认(W = 1)，我们就需要和所有的三个节点进行通话来确保我们可以获得最新的更新。在这种情况下，由于我们没进行写入仲裁，我们也许就会遭遇更新冲突，但只要从足够多的节点中读出数据，我们依然可以侦测出此类冲突。这样我们就可以得到强一致的读取即使我们在写入上没有强一致。

执行读取操作时所需联系的节点数（R）,确认写入操作时所需要征询的节点数（W）,以及复制因子（N）这三者之间的关系，可以用一个不等式来表示。那就是，只有当R + W > N时，才能保证读取操作的强一致性。

上面说的这些不等式都适用于“对等式分布模型”。如果我们使用“主从分布模型”，那么只需要向主节点中写入数据，这样就可以避免“写写冲突”（write-write conflicts）。同样的，只需要从主节点读取就可以避免“读写冲突”（ead- write conflicts）。在这种情况下，往往很容易就把集群的节点数与复制因子相混淆，傻傻分不清楚，然而他们是两个概念。比如，我可以有一个100个节点的集群，但复制因子却只有3，因为大部分数据都分布在各个“分片”之中。

事实上，很多权威都建议说复制因子为3就足够拥有不错的“故障恢复能力”（resilience）了。这时，如果只有一个节点出错，那么仍然能够满足读取和写入所需要的最小的法定节点数。如果有自动均衡机制（automatic rebalancing），那么用不了好久，集群就会自动创建一个“第三”副本，所以，在替代副本建立好之前，丢失掉“第二”副本的概率是很低的。

参与某个操作的节点数，可能会随着该操作的具体情况而改变。当我们写入数据时，根据“一致性”与“可用性”这两个因素的重要程度，有一些更新操作可能需要获得足够的节点的支持率才能执行，而另外一些则不需要。与之相似，某些读取操作可能更看重执行速度，而可以容忍过期数据，此时它就可以少联系几个节点。

通常你需要将这两方面都考虑进来。如果你希望访问速度够快同时还必须保证强一致性，那么写入操作就要得到所有的节点的确认才行，这样的话，只需要联系一个节点，就能完成读取操作了（N = 3, W = 3, R = 1）。这就意味着你的写入将会变得很慢，因为每次写入都 必须要和所有的三个节点联系，这种情况是不能容忍那怕一个节点出错。但在某些情况下，还是需要权衡一致性和可用性。

上面说了这么多，就是希望我们在“一致性”和“可用性”之间做出更好的权衡，“之间”是存在很多选项的，需要根据每个方案的优缺点最后选择一个适合自己的方案。有些NoSQL技术博客的作者认为一致性和可用性之间是一个简单的权衡。但我们希望在这里告诉你，让你意识到这两者间是有更灵活的选择和权衡，而不是简单的权衡，当然也更复杂一点。