redis脑裂

脑裂

Raft 集群存在脑裂问题。在多机房部署中，由于网络连接问题，很容易形成多个分区。
而多分区的形成，很容易产生脑裂，从而导致数据不一致。
由于三机房部署的容灾能力最强，所以生产环境下，三机房部署是最为常见的。下面以
三机房部署为例进行分析，根据机房断网情况，可以分为五种情况：

情况一不确定

这种情况下，B 机房中的主机是感知不到 Leader 的存在的，所以 B 机房中的主机会发
起新一轮的 Leader 选举。由于 B 机房与 C 机房是相连的，虽然 C 机房中的 Follower 能够感知到 A 机房中的 Leader，但由于其接收到了更大 term 的投票请求，所以 C 机房的 Follower也就放弃了 A 机房中的 Leader，参与了新 Leader 的选举。

若新 Leader 出现在 B 机房，A 机房是感知不到新 Leader 的诞生的，其不会自动下课，
所以会形成脑裂。但由于 A 机房 Leader 处理的写操作请求无法获取到过半响应，所以无法完成写操作。但 B 机房 Leader 的写操作处理是可以获取到过半响应的，所以可以完成写操作。故，A 机房与 B、C 机房中出现脑裂，且形成了数据的不一致。

若新 Leader 出现在 C 机房，A 机房中的 Leader 则会自动下课，所以不会形成脑裂。

情况二形成脑裂

这种情况与情况一基本是一样的。不同的是，一定会形成脑裂，无论新 Leader 在 B 还
是 C 机房。

情况三无脑裂

A、C 可以正常对外提供服务，但 B 无法选举出新的 Leader。由于 B 中的主机全部变为
了选举状态，所以无法提供任何服务，没有形成脑裂。

情况四无脑裂

A、B、C 均可以对外提供服务，不受影响。

情况五无脑裂

A 机房无法处理写操作请求，但可以对外提供读服务。
B、C 机房由于失去了 Leader，均会发起选举，但由于均无法获取过半支持，所以均无
法选举出新的 Leader。