希音面试：Redis脑裂，如何预防？你能解决吗？（看这篇就够了）

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

什么 Redis的脑裂问题？

什么Redis的脑裂， 后果是什么？ 如何解决？

Redis脑裂，如何预防？你能解决吗？

最近有小伙伴在面试 希音，又遇到了相关的面试题。小伙伴懵了，因为没有遇到过，所以支支吾吾的说了几句，面试官不满意，面试挂了。

所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V171版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，回复：领电子书

1：什么是脑裂问题?

脑裂(Split-Brain)是一个形象的比喻，好比“大脑分裂”，也就是本来一个“大脑”被拆分了两个或多个“大脑”。

在分布式系统中，因为网络分区或节点故障导致节点之间的通信断开，进而导致数据一致性问题。

在一个高可用集群中，当多个服务器在指定的时间内，由于网络的原因无法互相检测到对方，而各自形成一个新的小规模集群，并且各小集群当中，会选举新的master节点，都对外提供独立的服务。

由于网络断裂的原因，一个高可用集群中，实际上分裂为多个小的集群，这种情况就称为裂脑。

也有的人称之为分区集群，或者大脑垂直分隔，互相接管对方的资源，出现多个Master的情况，都可以称为脑裂。

裂脑之后的后果是，可能会导致服务器端的数据不一致，或造成数据的丢失

借助一个简单的 6个节点的 Zookeeper 集群为例，介绍一下脑裂。

这个要求，与ZooKeeper 的默认解决脑裂的策略有关系。

现在，为了高可用，将一个由 6 个节点的 zkServer 集群，部署在了两个机房，具体如下图：

正常情况下，此集群只会有一个 Leader，并且 集群的Leader节点通过投票选举的。就是集群通过选举的规则所有节点中选出来的，简称为选主。

如果意外的情况发生： 两个机房之间， 发生断网，结果如何呢？

这里有两个子网络，一个子网是3个节点，

发生断网后，一个大的集群， 其实被分割为 2个小的集群，每个小的集群各自3个节点，

2个小的集群 选举出各自的leader，对外提供服务， 发生脑裂。

1.1：脑裂严重后果：

发生脑裂后，系统被分割成两个或多个独立的子系统，每个子系统可能会独立选举出自己的领导节点（Leader）。

由于不同的子系统可能会对相同的数据进行修改, 这种情况可能导致数据不一致和操作冲突。

所以： 脑裂的严重后果是：数据一致性的丧失，这对于依赖精确数据进行操作的系统来说是致命的。

例如，在银行系统中，如果账户余额记录因为脑裂而不一致，可能导致用户资金被错误处理。

为了避免脑裂问题，Zookeeper采用了过半机制（Quorums），即只有集群中超过半数节点投票才能选举出Leader。

Redis 脑裂，在原理上和 Zookeeper 脑裂，ES 脑裂 ，本质上都是类似的：

具体请参见尼恩的文章：

聊聊：什么脑裂？ 照此文作答，面试官献上膝盖，秒发offer

Redis 脑裂，和Redis 集群的模式有关。

所以，在介绍脑裂之前，尼恩先给大家梳理一下Redis的四大集群模式，以及它们各自的应用场景，然后基于不同的模式，介绍脑裂问题。

2：Redis的四大集群模式

Redis的部署模式主要包括以下几种：

一、单机

二、主从复制

三、哨兵

四、集群

2.1： 单机部署

单机部署只有一台Redis实例，如果这台服务器宕机，服务也将随之中止，而且，由于数据没有进行备份，安全性也将大打折扣。

单机部署 应用场景

单机部署的复杂性较低，对于学习或者测试的目的，这种部署模式还是比较合适的，

而且，单机部署也是其它复杂部署模式的起点。

2.2：主从复制

主从复制将一个Redis服务器上的数据复制到其他服务器上，前者称为Master也就是master，后者为Slave也就是从节点，Master主要负责数据的写操作，Slave主要进行数据的读操作。

通过主从复制可以实现数据备份、读写分离、故障恢复等功能。

主从复制可以有多个从节点，在数据同步的过程中，它会存在一定的延迟，同时，异步的数据复制也不保证强一致性。如果master宕机，需要手动把从节点切换为master。

主从复制 应用场景

• 数据备份和容灾恢复：通过从节点备份master的数据，实现数据冗余。
• 读写分离：将读操作分发到从节点，减轻master压力，提高系统性能。
• 在线升级和扩展：在不影响master的情况下，通过增加从节点来扩展系统的读取能力。

总结：主从复制模式适合数据备份、读写分离和在线升级等场景，但在master故障时需要手动切换，不能自动实现故障转移。如果对高可用性要求较高，可以考虑使用哨兵模式或Cluster模式。

2.3：哨兵模式

哨兵模式是在主从复制基础上加入了哨兵节点，实现了自动故障转移。哨兵节点是一种特殊的Redis节点，它会监控master和从节点的运行状态。

当master发生故障时，哨兵节点会自动从从节点中选举出一个新的master，并通知其他从节点和客户端，实现故障转移。

主从复制有一个较为明显的缺点，就是master宕机后，系统不会自动切换，还需要人工介入，针对这样的情况，哨兵模式就应运而生了，它非常重要的一个优点就是能够实现自动故障转移。

当然，哨兵模式也并非完美的解决方案，除了实际存储数据的服务器，它还需要额外的哨兵服务，这样就增加了运维成本，同时，所有的数据都存放在一台机器（没有进行分片），使得存储的容量也有了限制。

哨兵模式场景应用
哨兵模式适用于以下场景：

• 高可用性要求较高的场景：通过自动故障转移，确保服务的持续可用。
• 数据备份和容灾恢复：在主从复制的基础上，提供自动故障转移功能。

哨兵模式在主从复制模式的基础上实现了自动故障转移，提高了系统的高可用性。

然而，它仍然无法实现数据分片。如果需要实现数据分片和负载均衡，可以考虑使用Cluster模式。

2.4： 集群模式

Redis集群使用哈希槽的方式将数据进行分片，分开存放在不同的机器上，这样就大大