Redis 脑裂深度解析：主从切换如何避免数据丢失与高可用配置

各位做后端开发的同学应该都遇到过这种诡异场景Redis 主从架构明明运行得好好的突然某一天查看监控发现主节点竟然“分身”了出现了两个主节点而且数据还不一致。更让人头疼的是旧主节点恢复后它自己写进去的一部分数据莫名其妙丢了。这到底是怎么回事是 Bug 还是配置错误其实这就是 Redis 高可用架构里非常经典的一个问题脑裂Split Brain。这篇文章我打算用尽可能通俗的方式把 Redis 脑裂的来龙去脉讲清楚包括它为什么会产生、什么时候会触发、如何通过配置最大限度避免以及真遇到数据丢失该怎么排查和恢复。文章会比较长但每一节都是实打实的干货无论是面试还是排障都能直接用上。1. 什么是 Redis 脑裂为什么会有两个主节点1.1 先从“主从复制”说起在解释脑裂之前我们先快速回顾一下 Redis 的主从复制模式。一个典型的 Redis 主从架构中只有主节点Master提供写服务从节点Slave通过REPLICAOF命令复制主节点数据提供读服务。这种模式解决了读流量的横向扩展问题但主节点依然是单点一旦 Master 宕机整个系统就无法写入。于是为了保证高可用我们引入了**哨兵Sentinel**机制。哨兵是一个独立的 Redis 进程它的核心职责是监控主从节点的健康状态并在主节点发生故障时自动执行故障转移Failover也就是从一堆从节点中选出一个新主节点并把其他从节点指向新主节点。1.2 脑裂的直观定义“脑裂”这个词听起来很吓人但其实描述非常形象。它指的是原本一个主节点由于网络分区、进程阻塞、或负载过高等原因导致哨兵无法正常接收到它的心跳因此哨兵判定主节点“已死”于是执行主从切换提升一个从节点为新主节点。然而旧主节点其实还在运行只是它与哨兵和其他从节点之间的网络连接断了。此时整个 Redis 集群中同时存在两个能够接收写请求的“主节点”一个是哨兵选出来的新主节点一个是网络分区另一侧的旧主节点。对于客户端来说如果它还连接着旧主节点并且继续写入数据那么这些数据不会被同步到新主节点上。因为旧主节点已经和从节点断开了连接复制链路已经断裂。等到网络恢复旧主节点发现新主节点存在它会尝试变成新主节点的从节点并执行全量同步。这时候旧主节点在“脑裂期间”写入的数据会因为新主节点没有这些数据而被丢弃相当于所有脑裂期间的写请求都“悄悄丢失”了。1.3 脑裂产生的直接原因脑裂并不常见但一旦出现就是生产事故。直接原因可以归结为以下几类原因分类具体场景说明网络分区交换机故障、网线松动、防火墙误杀主节点和哨兵/从节点被网络隔离但主节点进程本身还存活主机负载过高CPU 满负载、内存 swap 严重主节点线程无法及时响应哨兵心跳被误判为客观下线长耗时命令执行 KEYS *、大 key 删除、阻塞命令主节点进程阻塞心跳超时云环境故障虚拟机热迁移、宿主机网络抖动云盘 IO 抖动导致 Redis 无法及时处理网络请求本质上哨兵决定“主节点死亡”是通过两个条件判断的主观下线SDOWN和客观下线ODOWN。当一个哨兵实例发现主节点心跳超时它会先标记该主节点为主观下线当多个哨兵通常配置为 quorum 数量都认为主节点主观下线时才会标记为客观下线然后触发故障转移。问题就在这——“心跳超时”不等于“进程死亡”。2. Redis 高可用架构中脑裂的影响2.1 数据丢失是最大的危害脑裂最严重的后果就是数据丢失。前面提到过脑裂期间客户端仍然可能向旧主节点写入数据。由于旧主节点已经没有任何从节点可以同步它的数据只能停留在本机内存中。一旦网络恢复旧主节点为了保持数据一致性会主动降级为新主节点的从节点并进行全量复制或部分重同步具体看复制积压缓冲区大小。新主节点没有脑裂期间旧主的写入数据所以这部分数据会被无情覆盖。2.2 客户端写入行为“分裂”在脑裂期间部分客户端可能连接的是旧主节点部分客户端通过哨兵感知到的可能是新主节点。那么整个系统的数据写入路径就分裂了连接旧主的客户端写入成功但数据最终会丢失连接新主的客户端写入成功数据最终保留。这就会造成短期内业务数据不一致对强一致性要求较高的业务例如订单、库存影响尤为严重。如果业务没有做好重试和幂等处理甚至可能出现超卖、订单状态错乱等较为棘手的连锁问题。2.3 对 Redis 持久化机制的双重考验脑裂期间旧主节点如果配置了 AOF 或 RDB 持久化那么这部分数据会在本地文件系统留存。但当旧主节点变成从节点后Redis 的持久化行为会跟着新主节点走。也就是说即使你在本地文件里找到了脑裂期间的写入记录也不能直接把这些数据“补”回新主节点因为数据的 key 空间已经变了强行合并很可能引发更严重的数据冲突。3. 核心配置解析min-replicas-to-write 与 min-replicas-max-lagRedis 官方其实早就想到过脑裂和主从切换期间数据丢失的问题。在redis.conf中提供了一组保护参数min-replicas-to-write和min-replicas-max-lag。这两个参数常被人忽略但在生产环境里非常关键。3.1 参数含义这是一段典型的配置# 当从节点数量少于 1 个时主节点停止接受写请求 min-replicas-to-write 1 # 从节点与主节点的最大延迟单位秒 min-replicas-max-lag 10这两行配置的含义是主节点在接收写请求之前必须保证至少有min-replicas-to-write个从节点与它保持连接并且从节点的复制延迟不能超过min-replicas-max-lag秒。如果条件不满足主节点会拒绝写入返回错误。想象一下脑裂场景旧主节点和所有从节点断开连接此时它的从节点数变为 0小于配置值1那么旧主节点会立刻停止接受写入。这样一来即使客户端还在往旧主节点发写入请求也会被拒绝从而避免了脑裂期间的数据产生。3.2 参数的适用边界不过这里要特别说明这两个参数并不能完全避免脑裂本身它们只是降低了脑裂期间“产生新数据”的概率。脑裂依然会发生哨兵依然会切换主节点但只要旧主节点无法写入那么切换之后的数据就是干净的。另外这个保护在以下场景是无效的min-replicas-to-write设置为 0旧主节点上的从节点并没有全部断开例如它的部分从节点还连着此时它认为自己仍满足写入条件网络分区只是“单向的”比如主节点能收到客户端的写请求但发给哨兵的心跳被丢弃同时也收不到从节点的 ACK最终因 lag 超过阈值被拒绝写入。所以配置参数一定要结合业务场景。假设你的主节点本身一个从节点都没有单节点 Redis那么min-replicas-to-write 1会让主节点永远无法写入。这个参数通常只在主从架构或哨兵架构中使用。3.3 如何设置合理阈值min-replicas-to-write一般设置为1保证至少有一个从节点在线才允许写入。min-replicas-max-lag建议设置为哨兵down-after-milliseconds的 2 到 3 倍。比如哨兵配置down-after-milliseconds 5000那么这里可以设置为10。这样即使网络发生抖动也不会因为瞬时延迟把正常写入全部拒绝掉。4. 实战模拟复现一次 Redis 脑裂讲了这么多理论不如亲手模拟一次。下面我会用一个可复现的实验来演示脑裂是如何产生的以及数据是如何丢失的。需要说明的是下面的实验会用到 Docker和iptables模拟网络分区请务必在隔离的测试环境操作不要在生产环境执行。4.1 环境准备为了快速搭建我直接使用 Docker 创建三个 Redis 容器redis-master主节点端口 6379redis-slave-1从节点 1端口 6380redis-sentinel哨兵节点端口 26379我这里以 Redis 7.x 为例进行演示不同小版本命令上会有细微差异但整体思路是一致的。如果你本机没有 Redis 镜像可以先用docker pull redis:7拉取镜像。# 创建自定义网络保证容器之间可以互通 docker network create redis-split-brain # 启动主节点 docker run -d --name redis-master \ --network redis-split-brain \ -p 6379:6379 \ redis:7 redis-server --appendonly yes # 启动从节点 docker run -d --name redis-slave-1 \ --network redis-split-brain \ -p 6380:6379 \ redis:7 redis-server --appendonly yes --replicaof redis-master 6379 # 启动哨兵简单起见这里只启动一个哨兵 docker run -d --name redis-sentinel \ --network redis-split-brain \ -p 26379:26379 \ redis:7 redis-sentinel \ --sentinel monitor mymaster redis-master 6379 1说明一下上面哨兵配置中最后的1表示 quorum 为 1即一个哨兵就可以判定主节点客观下线。生产环境至少 3 个哨兵这里只是为了演示方便。4.2 验证主从状态先查看主节点和从节点的复制状态。docker exec redis-master redis-cli INFO replication正常情况下主节点输出中会包含role:master connected_slaves:1 slave0:ip172.x.x.x,port6379,stateonline,offset123,lag0从节点输出中会包含role:slave master_host:redis-master master_link_status:up这说明主从复制正常。4.3 模拟脑裂场景为了模拟脑裂我直接通过iptables规则把主节点到其他容器的网络连接全部切断。进入主节点容器执行docker exec -it redis-master bash # 在容器内执行阻断所有外部 TCP 连接仅仅模拟用 iptables -A INPUT -p tcp --dport 6379 -j DROP iptables -A OUTPUT -p tcp --sport 6379 -j DROP注意这里可能会提示没有权限需要在启动容器时加上--cap-addNET_ADMIN。如果你不想重新创建容器也可以直接用宿主机上的流量控制工具思路是一样的核心是让主节点“看起来失联了”。当主节点被隔离后哨兵很快就会判定主节点主观下线并执行故障转移。这时候再去看主节点会发现它仍然活着而且和客户端之间的连接已经断了但进程还在。与此同时哨兵已经将redis-slave-1提升为了新的主节点。4.4 在旧主节点上尝试写入现在理论上旧主节点应该已经无法接收外部写入因为它连接都断了。但如果是真实环境里客户端还在旧主节点的网络分区内那么旧主节点可能仍然接收请求。为了模拟这种情况我们直接在旧主节点容器内通过redis-cli写入数据docker exec redis-master redis-cli SET stock:001 100 docker exec redis-master redis-cli SET order:9527 paid在真实脑裂场景中如果旧主节点没有配置min-replicas-to-write保护这些写入是能成功的。因为我们用了容器隔离这里可以帮助理解数据是怎么“写进去了但同步不过去”。4.5 查看哨兵切换结果当旧主节点“恢复”网络后它发现自己的角色已经被改变会自动尝试重新加入集群并同步新主节点的数据。此时数据会怎样呢我们分别在旧主节点和新主节点上查询刚才写入的 keydocker exec redis-slave-1 redis-cli GET stock:001 docker exec redis-slave-1 redis-cli GET order:9527结果一定是(nil)因为新主节点从来没有收到过这些数据。再看旧主节点docker exec redis-master redis-cli GET stock:001它可能还有这个 key但过不了几秒等它完成与新主节点的全量同步后这个 key 也会消失。这就是脑裂导致数据丢失的完整过程。4.6 对照实验启用了保护参数的情况现在我们重新搭建一组 Redis并在主节点配置中加上min-replicas-to-write 1 min-replicas-max-lag 5然后重复上述网络分区模拟。这时候当主节点与从节点失去联系后你再向旧主节点写入数据它会直接返回错误(error) NOREPLICAS Not enough good replicas to write.这样的结果就是脑裂期间旧主节点拒绝了所有写请求等网络恢复后新旧主节点数据是一致的没有产生额外写入也就避免了数据丢失问题。5. 脑裂常见问题与排查清单如果你在生产环境怀疑发生了脑裂或者已经遇到了数据丢失建议按照下面的排查思路一步步确认。5.1 如何判断是否发生过脑裂可以通过以下手段判断查看 Redis 日志旧主节点上如果出现MASTER - REPLICA sync started或者Connection with master lost等日志说明它曾经与集群断开。查看哨兵日志哨兵日志中sdown、odown、switch-master等事件时间点非常关键。查看监控图表如果主节点的connected_slaves数量在某一时间段降为 0同时写入量仍然不为 0说明极有可能发生了脑裂期间的写操作。比对数据差异拿旧主节点 AOF/RDB 中的 key 与新主节点中的 key 数量做对比差异较大的部分多半就是丢失部分。5.2 高频问题速查表问题现象常见原因解决思路出现两个主节点哨兵误判主节点宕机网络分区检查网络稳定性、调整哨兵 down-after-milliseconds 阈值脑裂期间数据丢失旧主节点未配置保护参数开启 min-replicas-to-write 和 min-replicas-max-lag旧主节点恢复后频繁全量同步复制积压缓冲区太小或新主节点数据差异过大调大 repl-backlog-size或检查是否有大 key 清理任务客户端写入被拒绝min-replicas-to-write 设置不合理如果只有单主节点不要开启该参数多从节点场景确认数量哨兵频繁切换主节点主机 CPU/内存负载过高导致心跳超时优化慢查询、排查宿主机资源竞争、适当调大哨兵超时时间AOF 文件里能找到旧数据但恢复不了Redis 降级为从节点后执行了全量同步通过 RDB/AOF 备份恢复但注意备份时间点避免二次覆盖5.3 排查步骤建议遇到脑裂问题时建议的执行顺序立即停止对旧主节点的写入依赖可通过防火墙或调整客户端连接池备份旧主节点的 AOF 和 RDB 文件读取哨兵日志确认故障切换发生的时间点记录新主节点的复制偏移量并与旧主节点对比根据业务情况评估丢失数据量尝试从备份中找回修复根因例如优化网络、调整哨兵配置、开启保护参数确认集群状态正常后再恢复业务流量。6. 如何尽量避免 Redis 脑裂预防永远比事后修复更省心。下面分享一些我在实践中的经验。6.1 合理配置哨兵参数哨兵有几个关键参数直接决定了故障转移的灵敏度down-after-milliseconds哨兵与主节点之间连续多少毫秒联系不上就判定为主观下线。设置太短容易误判设置太长会导致故障恢复时间延长。建议根据实际网络质量设置一般5000到10000毫秒比较适中。sentinel failover-timeout故障转移超时时间。这个值如果太小可能在上一次故障转移还没完成时就又触发新的切换反而加剧脑裂风险。sentinel parallel-syncs故障转移后同时向新主节点发起同步的从节点数量建议设置为 1避免多个从节点同时全量同步造成新主节点压力过大。这里给出一份生产环境常用的哨兵配置模板sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 30000 sentinel parallel-syncs mymaster 1需要注意quorum值设置为 2意味着至少需要 2 个哨兵判定主节点主观下线才会执行切换能有效减少单点误判。6.2 使用 Redis Cluster 替代哨兵模式哨兵模式虽然能实现高可用但它本身不解决分片问题而且脑裂场景需要额外配置才能降低风险。如果业务规模允许建议考虑直接使用 Redis Cluster。Redis Cluster 内置了故障检测和选举机制每个主节点都有从节点当主节点失联时从节点发起选举只有获得多数派主节点的投票才能升级。这种多数派机制天然杜绝了脑裂因为不可能同时有两个主节点都能获得多数派支持。当然Redis Cluster 也不是完全没有数据丢失场景例如集群分片迁移过程中节点宕机但整体上比哨兵模式可靠很多。6.3 客户端层面的容错策略无论服务端怎么配置客户端都应该做好防御写入重试机制写失败后从哨兵获取最新主节点地址重新执行写入幂等设计写操作尽量带上唯一业务 ID即使重复执行也不会产生脏数据降级方案如果 Redis 短时间不可写可以降级到本地缓存或消息队列等 Redis 恢复后再异步回放监控告警对master_link_down_since_seconds、connected_slaves、role等指标设置告警主节点角色变化时第一时间通知运维。6.4 网络层面优化对于自建 Redis建议把 Redis 节点部署在同一个交换机下避免跨机房跨可用区的网络分区。如果必须跨机房部署就要接受脑裂风险并通过业务层面做妥协。另外开启 TCP keepalive防止长时间空闲连接被中间设备断开。在 Linux 内核层面还可以适当调整 TCP 重传参数减少偶发网络抖动引发的误判。常用参数如下# 缩短 TCP 重传时间快速感知网络异常 sysctl -w net.ipv4.tcp_retries13 sysctl -w net.ipv4.tcp_retries25这些值需要结合真实网络情况测试不要盲目照搬。6.5 备份策略不能少即使上面所有的保护手段都做了也不能保证 100% 不丢数据。所以持久化层一定要有兜底方案开启 AOF 持久化并设置appendfsync everysec定期执行BGSAVE生成 RDB 备份对于重要业务可以用额外的消费端订阅 Redis 的keyspace事件做实时旁路备份异地灾备场景可以使用 Redis 官方提供的redis-shake之类的同步工具把数据实时同步到灾备集群。7. 如果已经发生了脑裂和数据丢失怎么抢救如果事故已经发生保持冷静按下面的顺序处理7.1 立刻隔离旧主节点为了防止旧主节点反复切换先把旧主节点的网络隔离不要让客户端继续往旧主节点写入。可以直接用防火墙丢弃端口也可以在客户端层面摘除节点。# 在旧主节点宿主机上执行 iptables -A INPUT -p tcp --dport 6379 -j DROP7.2 备份旧主节点数据在隔离的同时立刻备份旧主节点的持久化文件。这里注意如果 AOF 文件还在可以尝试用redis-check-aof修复文件损坏问题然后通过临时实例恢复数据。# 备份 RDB cp /var/lib/redis/dump.rdb /backup/dump_$(date %F_%T).rdb # 备份 AOF cp /var/lib/redis/appendonly.aof /backup/appendonly_$(date %F_%T).aof7.3 分析数据差异将备份文件恢复到一台临时 Redis 实例上然后与新主节点做 key 比对。如果数据量很大可以使用redis-cli --scan导出所有 key再用脚本比对。对于 key 数量差异过大的场景通常只能接受丢失事实或者通过业务日志回放恢复。7.4 修复配置后再上线确认根因后修改配置并按照最小化变更原则逐步上线。上线后持续关注哨兵日志、主从复制状态和写入拒绝次数。8. 总结与学习路线理顺整个脑裂问题后会发现它并不是一个特别高深的技术概念本质上就是网络分区 哨兵误判 写入保护缺失三者叠加产生的数据一致性问题。面试中如果被问到能够围绕“哨兵主观下线/客观下线、故障转移、min-replicas 参数、数据丢失”这几个关键词展开再配合一个模拟实验复现过程基本就能讲得比较透彻。如果你今天第一次接触脑裂下一步建议按这个顺序继续深入亲手搭建一套 Sentinel 主从环境分别配置有保护和没保护两种模式模拟网络抖动观察现象多做几次故障注入实验例如用redis-cli debug sleep模拟阻塞看看哨兵多久会切换尝试把架构升级为 Redis Cluster对比一下哨兵模式和 Cluster 模式在故障切换上的行为差异最后再回归业务侧想想如果 Redis 真的丢了几秒数据你的业务有没有幂等和重试机制兜底。脑裂问题虽然可怕但只要你理解了它的触发机制提前配置好保护参数做好监控告警和备份策略生产环境完全可以把风险控制在可接受范围内。希望这篇文章的配置思路和排障清单能帮你在真实项目中少踩一些坑。