讨论帖：如果只有两个数据中心，使用 Raft 协议还有意义吗？

作者：disksing

对 Raft 有所了解的同学都知道，Raft 一般会使用奇数个节点，比如 3、5、7 等等。这是因为 Raft 是 一种基于多节点投票选举机制的共识算法，通俗地说，只有超过半数节点在线才能提供服务。这里超过半数的意思是 N/2+1（而不是N/2）。举例来说，3 节点集群需要 2 个以上节点在线，5 节点集群需要 3 个以上节点在线，等等。对于偶数节点的集群，2 节点集群需要 2 节点同时在线，4 节点集群需要 3 节点在线，以此类推。实际上不只是 Raft，所有基于 Quorum 的共识算法大体上都是这么个情况，例如 Paxos，ZooKeeper 什么的，本文仅以 Raft 为例讨论。

先考察一下为什么 Raft 通常推荐使用奇数节点而不是偶数节点。

共识算法要解决的核心问题是什么呢？是分布式系统中单个节点的不可靠造成的不可用或者数据丢失。Raft 保存数据冗余副本来解决这两个问题，当少数节点发生故障时，剩余的节点会自动重新进行 leader 选举（如果需要）并继续提供服务，而且 log replication 流程也保证了剩下的节点（构成 Quorum）总是包含了故障前成功写入的最新数据，因此也不会发生数据丢失。

我们对比一下 3 节点的集群和 4 节点的集群，Quorum 分别是 2 和 3，它们能容忍的故障节点数都是 1。如果深究的话，从概率上来说 4 节点集群发生 2 节点同时故障的可能性要更高一些。于是我们发现，相对于 3 节点集群，4 节点集群消耗更多的硬件资源，却换来了更差的可用性，显然不是个好选择。

但是！！！

上面说了，Raft 解决的核心问题有两个，分别是高可用和数据容灾。跟奇数节点相比，偶数节点的方案从可用性上看很不划算，但是数据容灾方面却是有优势的。还是以 4 节点为例，因为 Quorum 是 3，写入数据的时候需要复制到至少 3 个节点才算写入成功，假如此时有 2 个节点同时故障，这种情况下虽然不可用了，但是剩余的两个节点