redis集群的弱一致性

Redis集群不能保证强一致性。一些已经向客户端确认写成功的操作，会在某些不确定的情况下丢失。

产生写操作丢失的第一个原因，是因为主从节点之间使用了异步的方式来同步数据。

一个写操作是这样一个流程：

• 客户端向主节点B发起写的操作
• 主节点B回应客户端写操作成功
• 主节点B向它的从节点B1,B2,B3同步该写操作

从上面的流程可以看出来，主节点B并没有等从节点B1,B2,B3写完之后再回复客户端这次操作的结果。所以，如果主节点B在通知客户端写操作成功之后，但同步给从节点之前，主节点Ｂ故障了，其中一个没有收到该写操作的从节点会晋升成主节点，该写操作就这样永远丢失了。

就像传统的数据库，在不涉及到分布式的情况下，它每秒写回磁盘。为了提高一致性，可以在写盘完成之后再回复客户端，但这样就要损失性能。这种方式就等于Redis集群使用同步复制的方式。

基本上，在性能和一致性（C）之间，需要一个权衡。

如果真的需要，Redis集群支持同步复制的方式，通过WAIT 指令来实现，这可以让丢失写操作的可能性降到很低。但就算使用了同步复制的方式，Redis集群依然不是强一致性的，在某些复杂的情况下，比如从节点在与主节点失去连接之后被选为主节点，不一致性还是会发生。

这种不一致性发生的情况是这样的，当客户端与少数的节点（至少含有一个主节点）网络联通，但他们与其他大多数节点网络不通。比如６个节点，A,B,C是主节点，A1,B1,C1分别是他们的从节点，一个客户端称之为Z1。

当网络出问题时，他们被分成２组网络，组内网络联通，但２组之间的网络不通，假设A,C,A1,B1,C1彼此之间是联通的，另一边，B和Z1的网络是联通的。Z1可以继续往B发起写操作，Ｂ（主1）也接受Z1的写操作。当网络恢复时，如果这个时间间隔足够短，集群仍然能继续正常工作。如果时间比较长，以致B1（主2）在大多数的这边被选为主节点，那刚才Z1发给Ｂ的写操作都将丢失（多主脑裂）。

注意，Z1给Ｂ发送写操作是有一个限制的，如果时间长度达到了大多数节点那边可以选出一个新的主节点时，少数这边的所有主节点都不接受写操作。

这个时间的配置，称之为节点超时（node timeout），对集群来说非常重要，当达到了这个节点超时的时间之后，主节点被认为已经宕机，可以用它的一个从节点来代替。同样，在节点超时时，如果主节点依然不能联系到其他主节点，它将进入错误状态，不再接受写操作。