什么是Redis脑裂为什么主节点会突然变成两个之前在维护一套基于 Redis 哨兵Sentinel的高可用缓存环境时遇到了一个比较诡异的现象主节点突然出现拒绝写入同时监控面板上显示两个节点都曾是主节点。排查了半天最后定位到的问题是 Redis 脑裂Split Brain。关于这个问题的资料网上虽然不少但很多都停留在“什么是脑裂”的概念层面真正讲清楚触发过程、数据丢失原因、参数调优思路和复现方式的干货文章并不多。本文打算结合一次实际排障经历完整拆解 Redis 脑裂的前因后果并给出可复现的排查方法和工程建议。如果你是刚接触 Redis 的新手可以重点看前面两部分理解脑裂的概念和触发原理如果你已经在维护 Redis 主从或哨兵架构建议重点关注参数配置、模拟实验和最佳实践部分这几块内容可以直接应用到你的环境里。1. 什么是 Redis 脑裂要理解 Redis 脑裂建议先建立一个直观印象当一个 Redis 高可用集群中的部分节点因为网络问题无法互相通信时原本只有一台主节点Master的架构可能会变成两个甚至多个节点都认为自己是主节点并且同时接受客户端写入请求。这个现象在分布式系统领域有一个更通用的名词叫Split Brain脑裂。1.1 从主从复制说起在介绍脑裂之前有必要回顾一下 Redis 的主从复制和高可用机制。一个最基础的 Redis 高可用架构通常由下面几部分组成主节点Master负责处理写请求并将写操作同步给从节点。从节点Replica复制主节点的数据可以分担读请求并在主节点故障时被提升为新的主节点。哨兵Sentinel负责监控主从节点的健康状态在主节点不可用时自动执行故障转移Failover。正常状态下只有 Master 可以对外提供写服务从节点只是异步复制主节点的数据。当客户端往 Master 写入数据后Master 会立刻返回成功操作会异步传播给从节点。这里的“异步”两个字恰恰是脑裂导致数据丢失的根源之一。1.2 脑裂的专业定义从专业知识角度来定义Redis 脑裂指的是在网络分区Network Partition发生时部分节点与主节点之间的心跳通信中断但节点本身仍然存活。此时如果哨兵判定主节点客观下线并选出一个从节点提升为新的主节点那么旧主节点一旦恢复与客户端的通信就会出现两个主节点并存的局面。为什么会叫“脑裂”这其实是一个形象的比喻。原本一个大脑统一控制整个身体现在两个大脑各自为政发出的指令互相冲突。在 Redis 集群中两个主节点都在接受写请求但是它们之间的数据又无法及时同步最终就会出现数据分叉、丢失、覆盖等一系列问题。1.3 脑裂是网络抖动吗一个容易混淆的点是脑裂不是简单的网络抖动。网络抖动可能只是请求超时、延迟升高但节点的角色不会发生变化。脑裂是网络分区持续时间足够长触发了哨兵的故障转移机制之后才会出现的结果。换句话说脑裂是“主从切换流程”和“网络恢复”两个事件在时间上发生重叠产生的一种竞态问题。2. 为什么主节点会突然变成两个理解脑裂的关键在于梳理一条完整的时间线。很多开发者只知道“两个节点都成了主节点”但并不清楚这期间哨兵、主节点、从节点分别做了什么也不明白旧主节点为什么没有主动降级。下面用一个典型场景来还原整个事件过程。2.1 第一阶段网络分区导致心跳中断假设有一个 Redis 高可用架构包含1 个主节点 10.0.0.1:6379M12 个从节点 10.0.0.2:6379R1、10.0.0.3:6379R23 个哨兵节点 10.0.0.11:26379、10.0.0.12:26379、10.0.0.13:26379某一时刻机房网络发生故障M1 和哨兵、从节点之间的网络被切断。M1 本身没有宕机进程还在运行还能够接受本机或同网段客户端的连接只是无法和哨兵及从节点通信。Sentinel 发现与 M1 的心跳连续超时后会先将其标记为主观下线sdown。由于哨兵是多个节点组成的当一个哨兵认为主节点主观下线时还会向其他哨兵发起询问。2.2 第二阶段哨兵选举并提升从节点当足够多的哨兵都认为 M1 主观下线达到quorum配置的数量主节点就会被标记为客观下线odown。随后哨兵集群会选举一个 Leader 哨兵由它来执行故障转移流程。故障转移过程中哨兵 Leader 会从从节点中选出一个合适的节点。向选中的从节点发送SLAVEOF NO ONE命令让它成为新的主节点。其他从节点会重新指向新的主节点建立新的主从复制关系。此时 R1 被提升为新的主节点开始接受客户端的写请求。2.3 第三阶段网络恢复旧主节点重新上线问题出在第三阶段。当网络恢复后M1 和哨兵、其他节点重新建立了联系。M1 会发现自己连接的还是原来的主节点配置文件也就是说它仍然认为自己才是主节点。根据 Redis 的主从角色管理逻辑如果一个节点认为自己是主节点它就不会主动去复制其他节点的数据也不会自动降级为从节点。于是M1 和 R1 同时成为两个主节点各自接受写请求。这就是“为什么主节点会突然变成两个”的完整过程。2.4 为什么旧主节点不会自动降级很多人在排查脑裂时都会问网络恢复了旧主节点发现新主节点存在为什么不自动同步或者降级这需要理解 Redis 的设计哲学。Redis 的故障转移主要由外部组件哨兵或集群总线负责协调。节点本身不会主动去询问“集群里谁才是主节点”。旧主节点在网络分区期间无法感知其他节点的状态网络恢复后它只知道自己还运行在主模式下不会因为发现了另一个主节点就立刻改变自己的角色。在实际生产环境中如果哨兵配置了down-after-milliseconds比较小而网络抖动恢复时间比较长就很容易出现这种场景。这也是为什么脑裂问题在真实线上环境中并不罕见。2.5 脑裂可能发生在哪些场景主节点和哨兵之间网络闪断但主节点本身没有宕机。主节点所在宿主机负载过高导致 Redis 进程无法及时处理心跳请求被误判为下线。Redis 进程发生长时间 GC如果部署在 Java 同一台机器上或遇到虚拟机层级的停顿。主节点磁盘故障导致 IO 阻塞但进程仍然存活。云环境中的网络隔离、安全组变更等操作误伤主从节点之间的通信。其中主节点因为长时间 Full GC 或磁盘 IO 阻塞导致心跳超时是实际排障中常见的诱因。需要特别强调的是心跳超时不一定代表 Redis 真的挂了更准确的说法应该是“哨兵认为主节点不健康”。3. 脑裂会造成什么后果如果只是出现两个主节点但没有任何客户端写入脑裂可能只是日志里的一个警告。一旦客户端同时向两个主节点写入数据问题就会迅速放大。3.1 大量数据丢失这是脑裂最严重的后果。假设客户端在脑裂期间继续向旧主节点 M1 写入数据正常情况下M1 的写操作会通过主从复制同步给从节点。但在网络分区期间M1 无法将数据同步给任何从节点。哨兵提升 R1 为新主节点后数据以 R1 为准。网络恢复后M1 向新主节点同步数据时会先把自身的数据清空再执行 R1 的复制流。也就是说M1 在脑裂期间写入的数据在角色转换和重新同步过程中会被直接丢弃。对于缓存场景来说可能只是丢掉了一些可重建的数据如果是把 Redis 当作数据库使用或者存储了重要业务数据这就是严重的事故。3.2 缓存一致性问题即使业务方接受缓存数据可以丢失脑裂期间两个主节点各自独立写入后还会出现“新数据覆盖旧数据”的问题。例如旧主节点 M1 写入了 keyuser:1001valuehello。新主节点 R1 写入了同一个 keyvalueworld。网络恢复后M1 降级为从节点全量同步 R1 的数据。最终 user:1001 的值取决于 R1 的复制流M1 写入的数据被覆盖。对于依赖 Redis 缓存数据库一致性的业务这种覆盖可能导致一段时间内缓存和数据库内容不符。3.3 写入延迟升高或写入失败某些情况下脑裂还会造成客户端连接混乱。旧主节点 M1 和新主节点 R1 都接受写请求时客户端如果维护了连接池可能在不同请求之间访问到不同的“主节点”导致数据被分散写入两个地方。部分客户端如果配置了读写分离还有可能把写请求发送到降级后的旧主节点出现连接被拒绝、写入超时等异常。3.4 对哨兵集群判断造成干扰脑裂期间哨兵集群会持续监控节点状态。新主节点 R1 正常接受写入而旧主节点 M1 重新接入集群后哨兵集群可能会因为主节点角色冲突反复更新状态增加排查困难。如果架构中还叠加了 Redis Cluster情况会更复杂。这也是面试中经常把一个场景引申出来问的原因脑裂和数据丢失的关系是什么如何避免脑裂造成的数据丢失下面就来回答这个问题。4. 如何应对和解决 Redis 脑裂面对脑裂不能单纯指望 Redis 自动处理生产环境中更有效的手段是提前配置保护参数让旧主节点在异常条件下主动停止服务而不是继续接受写请求。4.1 核心参数min-replicas-to-write 和 min-replicas-max-lagRedis 提供了两个参数专门用来限制主节点在接受写入前必须满足的最少从节点数量和数据同步延迟要求min-replicas-to-write 1 min-replicas-max-lag 10min-replicas-to-write主节点最少需要有 N 个健康从节点连接才接受写请求。min-replicas-max-lag从节点与主节点之间允许的最大复制延迟以秒为单位即从节点从主节点拉取数据的最大滞后秒数。当主节点发现当前健康从节点数小于min-replicas-to-write或者从节点的延迟超过min-replicas-max-lag时主节点会拒绝写入请求返回错误(error) NOREPLICAS Not enough good replicas to write.4.2 参数保护脑裂的原理结合前面分析的脑裂场景再来看这两个参数的意义网络分区发生后旧主节点 M1 与从节点失联。M1 无法满足min-replicas-to-write的最低副本数要求。M1 会拒绝客户端写入。即使 M1 还活着也无法继续产生新数据。网络恢复后M1 向新主节点同步数据时不需要丢弃脑裂期间写入的数据因为没有新数据写入。这个保护机制的核心思路是用“拒绝部分可用性”来换取“数据一致性”。也就是说当 Redis 节点发现自己处于异常孤立的环境时宁可暂时不可写也不能让数据产生分叉。4.3 配置参数时的注意事项需要特别指出的是min-replicas-to-write不是简单的“配置了就安全”如果设置过小比如 0保护机制基本失效。如果设置过大比如 3但你的架构里只有两个从节点那么任何一个从节点宕机都会导致主节点拒绝写入影响可用性。需要结合从节点数量和业务写入容忍度来设置。一个常见的推荐配置至少 1 个从节点。min-replicas-to-write 1。min-replicas-max-lag 10。这样配置的好处是只要一个从节点掉线主节点就停止写入。对于大多数业务来说短暂的不可写可以通过服务降级或排队缓解但数据丢失往往更难接受。4.4 哨兵配置调整除了上述参数合理配置哨兵的down-after-milliseconds也很重要。这个参数决定了一个哨兵在多久没有收到主节点心跳后会认为主节点主观下线。sentinel monitor mymaster 10.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000down-after-milliseconds不要设置过小避免短时间网络抖动就触发主从切换。failover-timeout故障转移超时时间过小可能导致故障转移尚未完成就再次触发新的转移。如果网络环境本身不稳定建议适当调大down-after-milliseconds比如设为 10 秒或 15 秒。但这会带来另一个问题主节点真正宕机时Redis 服务不可用的时间会变长。这是一个需要权衡的选择。4.5 客户端层面规避客户端层面也可以做一些保护写入前使用INFO replication命令检查当前连接节点的角色和连接状态。连接池中动态维护主节点地址在主从切换后及时更新。配合服务端参数对写入失败的请求进行降级处理。不过正常情况下应该优先通过服务端参数保证旧主节点在异常时拒写客户端层面的检查只能作为辅助手段不能作为主要防御。5. 模拟实验复现一次 Redis 脑裂技术文章如果只讲原理和参数总感觉不够落地。下面用一个尽量简单的实验演示如何在本机复现脑裂场景。使用 Docker 会比较方便请根据你自己的实际环境调整版本和命令。5.1 环境准备需要准备Docker用于快速创建 Redis 主从和哨兵。redis-cli本地客户端也可以直接进入容器执行。这里以一个简单的拓扑为例角色地址主节点127.0.0.1:6379从节点127.0.0.1:6380哨兵127.0.0.1:263795.2 创建主从和哨兵先创建 Docker 网络docker network create redis-lab启动主节点和从节点docker run -d --name redis-master \ --network redis-lab \ -p 6379:6379 \ redis:7.0 redis-server --appendonly yes docker run -d --name redis-replica \ --network redis-lab \ -p 6380:6379 \ redis:7.0 redis-server --appendonly yes --slaveof redis-master 6379启动哨兵docker run -d --name redis-sentinel \ --network redis-lab \ -p 26379:26379 \ -e SENTINEL_QUORUM1 \ redis:7.0 redis-sentinel /etc/redis/sentinel.conf注意如果你本机没有标准sentinel.conf可以先把哨兵配置模板复制到容器中或者挂载一个自定义配置文件。以下是一个最简哨兵配置内容port 26379 sentinel monitor mymaster 127.0.0.1 6379 1 sentinel down-after-milliseconds mymaster 3000 sentinel failover-timeout mymaster 10000 sentinel parallel-syncs mymaster 15.3 模拟网络分区复现脑裂最直接的方法就是切断主节点和从节点、哨兵之间的网络同时保持主节点进程存活并可以让客户端继续访问。Docker 环境下可以使用iptables限制流量。进入主节点容器模拟丢弃所有从哨兵网段进入的数据包docker exec -it redis-master bash # 在容器内执行 iptables -A INPUT -s 172.18.0.0/16 -j DROP不过容器内执行iptables可能需要--privileged运行容器。如果条件不具备更简单的方式是直接暂停主节点容器中的 Redis 进程但这个方式不太能模拟“节点存活但网络不通”的情况。这里仅演示思路实际操作时可以结合tc命令流量控制模拟网络延迟和丢包。例如在主节点上增加 2000ms 延迟docker exec -it redis-master bash # 容器内执行需要安装 iproute2 tc qdisc add dev eth0 root netem delay 2000ms5.4 观察脑裂现象如果网络分区成功哨兵会在down-after-milliseconds后判定主节点主观下线并执行故障转移。此时使用redis-cli -p 26379 info sentinel查看当前主节点指向。使用redis-cli -p 6380 info replication查看从节点是否已经被提升为 Master。尝试向旧主节点 6379 写入数据。如果已经配置了min-replicas-to-write写入会失败返回NOREPLICAS错误。如果没有配置这个参数写入会成功但数据在后续同步时会被覆盖或丢失。5.5 实验结果说明配置情况实验结果未配置 min-replicas旧主节点继续接受写入脑裂期间产生数据配置 min-replicas-to-write 1旧主节点拒写数据不会发生分叉配置 min-replicas-max-lag 10复制延迟超过 10 秒时拒写这个实验虽然受限于 Docker 网络环境可能无法做到和物理网络完全一致但核心流程是清晰的只要旧主节点发现自己没有健康从节点而选择拒写脑裂造成的数据丢失就可以被有效控制。6. 常见问题与排查思路实际排查 Redis 脑裂问题时下面几个问题出现频率较高。问题现象常见原因解决思路业务写入报错 NOREPLICAS主节点健康从节点数低于 min-replicas-to-write检查从节点是否故障、网络是否分区优化参数配置主从切换后缓存大量过期脑裂期间旧主节点写入的数据被丢弃不要将 Redis 作为唯一数据源对于重要数据考虑双写或持久化策略哨兵显示两个主节点网络恢复后旧主节点未自动降级手动执行REPLICAOF让旧主节点重新成为从节点主节点 CPU 高但心跳超时宿主机负载过高影响 Redis 进程调度优化部署、调整 down-after-milliseconds脑裂恢复后 key 值被旧数据覆盖两个主节点写入同一 key 后同步冲突配置 min-replicas 参数客户端幂等重试排查清单可以按以下顺序执行确认表面现象哪个节点被提升为主哪个节点仍在写入。用INFO replication查看两个节点的角色和复制状态。用INFO sentinel查看哨兵视角的主节点状态。检查主从节点之间的网络连通性ping、telnet、redis-cli -h xxx ping。检查系统日志、Redis 日志、Sentinel 日志确认主观下线和客观下线的时间点。检查min-replicas-to-write和min-replicas-max-lag的配置值。根据配置和历史写入流量评估数据丢失范围。7. 最佳实践与工程建议下面这些建议是从实际维护经验中总结出来的比较通用适用于大多数 Redis 主从 哨兵架构。7.1 合理设置副本保护参数在 Redis 配置文件中加入以下配置并对每个主节点生效min-replicas-to-write 1 min-replicas-max-lag 10如果从节点数量较多可以适当调大min-replicas-to-write。但要注意这不是一个可以盲目调大的参数要结合业务对可用性的要求来平衡。7.2 配置命令动态生效线上已经运行的 Redis 可以通过CONFIG SET动态调整参数不需要重启redis-cli -h 127.0.0.1 -p 6379 CONFIG SET min-replicas-to-write 1 redis-cli -h 127.0.0.1 -p 6379 CONFIG SET min-replicas-max-lag 10使用CONFIG REWRITE将当前配置写入配置文件避免重启后丢失redis-cli -h 127.0.0.1 -p 6379 CONFIG REWRITE7.3 不要把 Redis 当作唯一数据源脑裂即使通过参数保护也不能保证 100% 不丢数据。比如主节点宕机瞬间已经返回客户端成功的写请求可能还没有同步到从节点此时从节点被提升为主节点这部分数据依然会丢失。因此比较稳妥的做法是Redis 只做缓存或加速层最终数据落库在 MySQL、PostgreSQL 等持久化存储中。对 Redis 中的数据进行重建或回源是业务设计上必须考虑的问题。7.4 启用 AOF 和 RDB 持久化虽然持久化不能解决脑裂问题但它能降低节点宕机后的数据丢失范围appendonly yes appendfsync everysec同时建议定期备份 RDB 文件并演练数据恢复流程。7.5 监控与告警日常监控主要关注以下指标主节点角色变化次数。connected_slaves数量变化。哨兵日志中的switch-master事件。复制延迟master_repl_offset和slave_repl_offset之间的差值。NOREPLICAS错误出现的频率和持续时间。建议在监控平台配置这类告警只要有主从切换事件发生就通知值班人员检查。脑裂本身不一定导致业务故障但它往往是网络或部署问题的前兆。7.6 网络规划和变更管理从架构层面减少脑裂风险也是重要手段主节点和从节点尽量部署在不同机架或可用区但要保证网络质量。避免将哨兵节点与主节点部署在同一台物理机。进行云平台安全组、防火墙变更时提前评估对 Redis 节点通信的影响。对宿主机负载、磁盘 IO、内网带宽做容量规划避免单点过载。7.7 恢复标准化操作如果已经发生脑裂建议按下面的标准操作恢复停止向旧主节点的写入流量。确认新主节点的数据状态。将旧主节点降级为从节点redis-cli -h 127.0.0.1 -p 6379 REPLICAOF new-master-ip 6379验证复制状态确认master_link_status:up。清理旧主节点上可能残留的过期数据以新主节点为准。在生产环境执行 REPLICAOF 之前一定先评估当前节点扮演的角色确认不会误伤正在服务的业务。8. 总结与下一步学习建议Redis 脑裂本质上是一个分布式系统的一致性和可用性取舍问题。在主从 哨兵架构中网络分区、心跳超时和自动故障转移之间的竞态是脑裂产生的根本原因。配置min-replicas-to-write和min-replicas-max-lag核心目的不是阻止故障转移而是让异常节点的写入能力被主动切断从而避免数据分叉和丢失。如果你使用的是 Redis Cluster脑裂的细节会有所不同。Cluster 模式依赖 gossip 协议维护集群状态在分区场景下会通过cluster-node-timeout和槽位分配来限制请求。建议可以把主从 哨兵模式理解透彻之后再对比着学习 Redis Cluster 的故障转移机制会有更加清晰的认知。下一步可以尝试自己动手做一次故障模拟实验比如用脚本批量写入数据同时触发主节点网络隔离观察数据变化和参数配置的作用。亲手验证过一次对脑裂的影响和参数效果会理解得更加牢固。如果本文对你有帮助欢迎收藏备用后续排查 Redis 高可用问题时可以快速查阅。