很多人第一次听到“脑裂”这个词是在面试官嘴里。第二次可能就是在线上事故总结里。Redis集群的脑裂问题简单来说就是同一个Redis集群里的主从节点因为网络问题分成了两个“派系”各自都以为自己是老大最后数据对不上谁的数据该留、该丢全靠运气。我最近在复习Redis集群相关知识点把主从复制、哨兵模式、集群模式几个部分重新撸了一遍发现脑裂这个坑几乎贯穿了所有高可用方案。这篇文章就用来彻底复盘一次从原理到实操从模拟到防护再到面试会怎么问一次讲清楚。1. Redis集群为什么会出现脑裂问题1.1 先从架构说起主从复制与哨兵要理解脑裂不能只盯着它本身得先把Redis高可用的基本盘搞明白。Redis集群有三种常见的形态单机、主从复制主从模式、哨兵模式基于主从复制、Redis Cluster集群模式多主多从。很多人会把“哨兵”和“集群”混在一起其实哨兵只是用来监控主从复制架构中的主节点做主节点的故障自动切换failover而Redis Cluster则是数据分片把数据按哈希槽分布在多个主节点上每个主节点又可以带从节点它自己也有高可用切换机制。不管是哨兵模式还是Cluster模式本质上都依赖主从复制。主节点master负责写请求从节点slave/replica负责读请求和备份。正常情况下主从之间通过复制流保持数据同步。一旦主节点挂了哨兵或者集群内部的协调机制会从从节点里选出一个新主节点继续对外服务。这套机制是为了高可用但也埋下了脑裂的种子。我画过一张简化思维模型Redis的主从架构就像团队里的“组长”和“组员”。组长掌握所有写入组员同步组长。如果组长暂时联系不上但并没有真的死掉团队可能会选出新的组长而旧组长又突然恢复两个组长同时说话下面的人就懵了。这个在分布式系统里不是一个新问题Raft等共识算法专门解决它但Redis在很长一段时间里并没有那么强的强一致保证用的还是“异步复制哨兵判断”这套方案所以脑裂更容易发生。1.2 脑裂的定义与核心成因脑裂split-brain在分布式系统里的正式定义是由于网络分区network partition或者节点故障一个集群被分成两个或多个部分其中两个部分都对外提供服务都以为自己是“主”或“唯一合法者”导致状态不一致。在Redis场景下最常见的触发点就是主从切换。来看一个很典型的时序主节点master-A和哨兵、客户端之间的网络发生分区但master-A进程没有挂还在运行它仍然可以接收本机客户端的写请求。哨兵集群因为收不到master-A的心跳或者大多数哨兵判断它主观下线触发客观下线然后执行故障转移把某个从节点slave-B提升为新的主节点master-B。这时客户端路由如果仍然连到旧的master-A比如客户端自己没感知到新主或者使用了旧连接就会继续往master-A写数据。一段时间后网络恢复master-A发现自己和哨兵能通信了哨兵会要求它降级为从节点同步master-B的数据。于是在这一段时间内写入master-A的数据就会因为“方向反了”而被覆盖或丢弃——因为这些数据根本没来得及复制给别的从节点。这就是脑裂导致数据丢失的完整链条。要注意“网络分区”未必是物理断网更多时候是负载过高导致的心跳超时、长GC停顿、服务器网卡故障等。Redis默认的timeout参数是0不限制但哨兵判断主观下线的sentinel down-after-milliseconds默认是30秒。如果这台机器发生了一次长时间的Full GC或者网络抖动超过了这个阈值就会触发误判——主节点其实活得很好硬被“下葬”了。这个节点很容易被忽略。我经常在排查线上问题时发现明明机器很健康却出现了failover一看监控主节点当时的CPU使用率接近100%GC停了十几秒哨兵等不到心跳就判了死刑。所以脑裂问题本质上是在高可用自动切换和一致性之间选择了“可用性”牺牲了“一致性”。2. 脑裂的本质网络分区与选主机制2.1 网络分区下的“两个老大”分布式系统里有个著名的CAP理论网络分区发生时你要么保一致性Consistency要么保可用性Availability不能两者兼得。Redis的高可用方案走的是“AP”路线优先保证系统能继续服务允许一段时间内数据不一致。这就是为什么会有脑裂——不是bug而是设计取舍。Redis哨兵模式中一个高可用集群通常有3个或5个哨兵实例。当网络分区把master和一部分哨兵隔开另一部分哨兵和从节点在一起哨兵是如何决策的核心是quorum法定人数。哨兵通过投票判断master是否真的挂了如果超过一半的哨兵认为master客观下线就发起故障转移。注意这里的quorum是针对哨兵的投票而不是所有节点。在这个过程中旧master可能还活着它根本不知道哨兵已经把它“开除”了。它继续接收写请求继续认为自己是master。等网络恢复旧master收到新master的复制命令时才发现自己已经不再是老大不得不变为slave但此时已经晚了——多出来的那段时间的写入数据已经成了孤儿数据。有一个容易误解的点很多资料说“脑裂一定会发生主从切换”其实不是。只要你开启了自动故障转移就有发生脑裂的可能。即使哨兵配置了合理的quorum也不能完全避免因为quorum只保证“决策一致”不保证“旧主停止服务”。哨兵能保证的是“大多数哨兵都认为该切换了”但它没法让旧主立即自杀。2.2 数据丢失是如何发生的前面说了脑裂导致的数据丢失根源在于旧主在“被降级”之前继续写入而这些写入没有被复制到其他节点。这里要深入一点Redis主从复制默认是异步的。所谓异步复制就是主节点收到写命令后先自己执行然后立即返回客户端成功接着才把命令通过复制流传给从节点。如果从节点还没来得及同步主节点就出了幺蛾子那部分数据就丢了。脑裂场景中旧主的写入根本传不出去因为网络分区了。就算网络恢复旧主降级为从节点它的复制缓冲区可能被新主的数据覆盖或者直接执行全量重同步那段时间的写入就全丢了。具体丢多少数据取决于三个变量网络分区持续的时间分区越久旧主被写入的数据越多。旧主接受到的写入量如果旧主侧没有客户端连接那也不会写入太多。主从切换的时间新主从选举到对外服务中间也可能有写入。这里补充一个数值案例假设哨兵的主观下线阈值是30秒旧主在分区期间每秒接收1000次写请求那么一旦发生切换最多可能丢失30000条数据。如果业务涉及转账、下单这个量级绝对是事故级。所以我们在复盘时第一句话往往会问分区了多少秒写了多少数据2.3 为什么默认配置更容易踩坑很多人用Redis直接按网上的教程配好哨兵就上线了根本没碰过那两个关键的防护参数。Redis从某个版本开始提供了min-replicas-to-write老版本叫min-slaves-to-write和min-replicas-max-lag参数。但默认情况下它们不生效。具体来说min-replicas-to-write主节点至少要有N个健康的从节点连接才接受写请求。如果健康的从节点数量小于N主节点会拒绝写入返回错误。min-replicas-max-lag从节点的数据复制延迟不能超过M秒。如果某个从节点的延迟超过M这个从节点就不算“健康”。这两个参数合起来的意思是主节点只有在至少有N个从节点并且这些从节点的复制延迟都在可接受范围内时才处理写请求。这样一来当网络分区把主节点和所有从节点都隔开时旧主那边健康的从节点数会降到0旧主就会拒绝写入从而把“孤儿数据”的窗口堵住。但为什么说默认更容易踩坑因为Redis很多默认配置是“高可用优先”的比如min-replicas-to-write默认是0min-replicas-max-lag默认是10但min-replicas-to-write0意味着不启用。很多教程甚至不提这个参数导致运维同学根本没意识到还有这么个保护开关。还有在Redis Cluster模式下虽然每个主节点也有对应的从节点但同样存在类似问题可以通过cluster-require-full-coverage、cluster-node-timeout等参数来做一定控制但依然不能完全杜绝脑裂。提示不要把min-replicas-to-write当成灵丹妙药。它只能减少脑裂导致的数据丢失窗口不能完全避免。业务层面依然需要幂等、重试、补偿等机制兜底。3. 实操模拟脑裂并配置保护参数3.1 快速搭建一个带哨兵的Redis主从集群为了把脑裂问题看明白我建议你自己动手模拟一次。下面我给出一个可以快速用Docker跑的方案虽然生产环境不推荐全容器化部署但用来做实验足够了。我用docker-compose起一个最简单的架构1个主节点、1个从节点、3个哨兵。目录结构大概是redis-split-brain-lab/ ├── docker-compose.yml ├── redis/ │ ├── redis-master.conf │ └── redis-replica.conf └── sentinel/ ├── sentinel1.conf ├── sentinel2.conf └── sentinel3.confdocker-compose.yml里定义6个服务。主从配置核心是# redis-master.conf port 6379 appendonly yes appendfsync everysec # redis-replica.conf port 6379 slaveof redis-master 6379 appendonly yes appendfsync everysec哨兵配置核心是# sentinel.conf port 26379 sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000 sentinel parallel-syncs mymaster 1这里down-after-milliseconds设置成5秒方便我们快速触发故障转移。注意生产环境中这个值一般会调到10秒以上避免频繁误判。3.2 模拟网络分区复现数据丢失要让旧主“假死”最直接的办法是让master节点失去和哨兵及其他节点的连接但进程不能退出。比如在Docker环境里可以用docker pause命令暂停master容器。步骤启动整个集群。往master写入一些数据确认可以正常写。执行docker pause redis-master模拟网络分区实际上是把进程挂起相当于心跳停止。等哨兵检测到master主观下线然后完成客观下线和failover。观察新主上线。然后docker unpause redis-master让旧主恢复。这时候你再看旧主它已经变成slave了。如果你在pause期间通过旧连接的客户端写入了数据这些数据就会失踪。具体操作时要注意Docker pause会让整个进程冻结和网络分区的效果略有差异但不影响观察脑裂和failover。更真实的模拟可以用iptables或tc做网络隔离但实验环境下Docker pause已经足够直观。写数据时我会用一个循环来记录丢失量比如# 客户端A连旧主 while true; do redis-cli -h 127.0.0.1 -p 6379 SET user:$RANDOM $RANDOM sleep 0.1 done等故障转移完成后统计新主上的key数量再对比旧主上曾经写入的数量就能直观看到差异。这里有个小细节如果你用的是旧连接在Docker pause期间redis-cli可能会一直阻塞等待响应而不是直接报错。这是因为TCP连接还挂着服务器进程被暂停了客户端发出去的命令得不到任何响应。等旧主恢复后那些命令才会陆续返回。所以模拟时最好配合timeout命令或者异步写入不然循环会卡住。3.3 用min-replicas-to-write和min-replicas-max-lag保护数据模拟完脑裂我们再给主节点加上保护参数。在redis-master.conf里加上min-replicas-to-write 1 min-replicas-max-lag 10这里min-replicas-to-write 1要求主节点至少要有1个健康的从节点才允许写。当master被pause后它的健康从节点数是0所以即使客户端的连接还在也会被拒绝写。这样一来数据丢失窗口就被堵住了。实际操作中你会看到旧主在分区期间执行写命令会返回如下错误(error) NOREPLICAS Not enough good replicas to write.这个错误信息非常明确没有足够的健康从节点不让你写。注意min-replicas-max-lag的作用是判断从节点是否“健康”。如果从节点因为网络问题同步延迟超过10秒那么即使连接还在也不算健康。两个参数通常要配合使用。还有一点如果集群里只有一个从节点min-replicas-to-write 1就意味着只要从节点有一点延迟或者断连主节点就拒绝写入这可能会降低可用性。生产上要根据实际情况权衡比如设置成1或2延迟阈值设置成10到30秒。3.4 其他相关配置cluster-require-full-coverage等如果你是Redis Cluster模式而不是哨兵模式有几个参数和脑裂相关cluster-node-timeout集群节点判断其他节点下线的时间阈值默认15秒。过小容易误判过大故障转移慢。cluster-require-full-coverage默认yes表示所有哈希槽都有节点服务时集群才接受请求。如果因为节点故障导致部分槽没有覆盖整个集群会停止服务等待槽恢复。这个参数其实是在“一致性”和“可用性”之间做了选择。如果设置为no集群会在部分槽缺失时继续接受请求但那些槽上的数据访问会失败或拿不到也可能出现不一致。通常建议保持默认yes但这样会在节点故障时牺牲部分可用性。cluster-replica-no-failover可以控制从节点是否需要参与故障转移在一些特殊场景下可以用来减少脑裂风险。这些参数在不同版本中名字可能略有差异比如之前的min-slaves-to-write在Redis 5之后废弃改名为min-replicas-to-write。如果你用的老版本可能还需要用老名字。我见过一些老项目的配置里还在用min-slaves-to-write启动时会看到warning建议升级时顺手改掉。4. 常见问题与排查技巧实录4.1 脑裂发生后的典型表现线上如果发生了脑裂你可能会看到这些现象监控图表上出现断崖式数据丢失之前写入的数据在切换后突然消失。主从切换日志和哨兵日志里能看到多次failover尝试或者有“选举失败”“failover-abort”之类的记录。客户端出现大量连接重置或主从切换导致的报错。info命令里出现主节点反复改变身份的记录master - slave - master。如果使用了redis-cli -a xxx info replication能看到某个节点的role发生变化master_replid变化master_repl_offset回退。如果你发现客户端曾经连接过旧主而旧主后面变成了slave那大概率脑裂已经发生过了。但很多场景下脑裂是悄悄发生的业务没有明显报错只是数据对不上等最终对账才发现出了问题。4.2 排查命令与日志分析排查脑裂我一般按以下顺序走第一确认主从切换发生的时间点。看哨兵日志docker logs sentinel1 --since 30 minutes ago关注关键词switch-master、sdown、odown、failover-state-wait-start等。这些日志能告诉你哨兵是什么时候发现的切换到了哪个节点。第二确认旧主上都发生过哪些写入。如果开了AOF可以尝试分析旧主的AOF或RDB但通常降级后数据可能已经被新主的复制流覆盖所以更可靠的是看客户端日志或业务日志查一下在那个时间窗口内哪些请求返回了成功。第三检查配置参数是否生效redis-cli -p 6379 config get min-replicas-to-write redis-cli -p 6379 config get min-replicas-max-lag如果没有设置你就知道为什么没防住了。第四如果用了Redis Sentinel看sentinel master mymaster输出的信息了解当前主节点和从节点状态。用sentinel get-master-addr-by-name mymaster获取当前主地址确认客户端是否连接的是新主。这里补充一个容易忽略的点排查时一定要对比“旧主上的主从切换时间”和“业务异常时间”。有时候哨兵日志里的切换时间比业务感知到的数据异常早很多那可能是客户端缓存了旧地址一直没重连。所以客户端侧也要看连接池的配置是否设置了主动探查和自动重连。4.3 经验速查表不同场景下的应对策略我整理了一个表格方便大家对照场景可能原因应对策略主节点短暂卡顿导致误切换大key操作、Full GC、网络抖动调大sentinel down-after-milliseconds治理大key和慢查询网络分区导致旧主仍在写交换机故障、网线松动、防火墙策略开启min-replicas-to-write和min-replicas-max-lag哨兵选主投票频繁失败quorum配置不合理、哨兵实例分布不均哨兵至少3个分布在不同物理机合理设置quorum客户端长期连接旧主客户端未感知新主地址使用支持故障转移的客户端库在业务层做好重连逻辑切换后从节点无法同步复制积压缓冲区不足、网络恢复后全量重同步调大repl-backlog-size提前演练主从切换这张表是我在实际运维中反复碰到的几种情况。特别要提一下大key问题一个几兆的list或者hash在主节点上执行del或者写操作可能会导致主节点阻塞几百毫秒甚至几秒哨兵等不到心跳就误判这是非常常见的隐性脑裂诱因。所以排查的时候不要只盯着网络慢查询和redis延迟监控也要一起看。4.4 面试角度这个话题的考点与回答思路很多人复习Redis集群就是为了过面试。脑裂这个话题面试官通常这么问“Redis主从切换时如果主节点没有挂还会产生脑裂吗数据会丢吗怎么解决”回答思路我建议分三步先解释什么叫脑裂用一句话说明主从集群因网络分区被分成两个部分旧主还在接收写请求同时哨兵又选出了新主恢复后旧主降级这段时间的数据就丢了。再说数据为什么会丢Redis主从复制是异步的旧主的写入没有复制给任何从节点。最后讲解决方案启用min-replicas-to-write和min-replicas-max-lag让主节点在没有足够健康从节点时拒绝写入同时从业务层加幂等和重试保证最终一致性。如果面试官追问“为什么min-replicas-to-write不能完全避免脑裂”你可以答它只能减少旧主在分区期间的写入量但如果从节点本身延迟很大或者只有一个从节点且它在分区时仍然连着旧主极端情况还是有可能在切换时出现少量数据丢失。Redis本身不是强一致系统这是它的取舍。5. 从脑裂衍生出去的思考5.1 分布式锁与脑裂RedLock真的安全吗讲完脑裂我想顺便多说一点因为这跟近期的热词“redis分布式锁”关系很大。很多人用Redis做分布式锁比如用来防并发通常用SET key value NX EX操作。但脑裂会直接影响分布式锁的安全性。如果旧主因为脑裂还在继续服务客户端A可能在旧主上成功加锁而另一个客户端B在新主上也能成功加锁两个客户端同时持有锁互斥就失效了。更严重的是锁的超时时间在主从间复制也有延迟可能出现锁提前释放。业界有争议的RedLock就是多节点锁方案号称能容忍单个节点故障但前提是节点之间要保证“不脑裂”。如果多个Redis节点之间发生了分区RedLock同样可能失效。所以很多分布式系统专家并不推荐用Redis做强互斥锁而更建议数据库锁、ZooKeeper或etcd这类带共识机制的组件。但如果你一定要用Redis分布式锁建议至少开启持久化和上面的保护参数并接受它可能失效的现实。5.2 业务侧如何兜底幂等与延迟双删从我这边的经验看解决脑裂不能只靠Redis配置业务侧一定要做兜底。最基础的两个方案幂等所有关键写操作带上唯一请求ID服务端做去重。这样即使发生了数据丢失或重复写入客户端重试后也不会造成重复数据。补偿如果发现数据丢失比如订单状态不对通过定时对账和补偿任务把数据重新补写回去。另外“缓存延迟双删”也是一个常用技巧先更新数据库再删除缓存过一小段延迟再次删除缓存。这是为了防止并发读写下缓存出现脏数据。脑裂期间旧主上的缓存数据可能是脏的双删会减少这种脏数据存活的时间。提示不管用哪种方案都要先和业务同事约定好“可以接受多大的数据丢失”。如果完全不能容忍丢失那Redis就只适合做缓存不适合做存储。最后再分享一点我自己的习惯在部署Redis高可用集群时我会把min-replicas-to-write、min-replicas-max-lag这些参数写进配置模板同时把哨兵的sentinel down-after-milliseconds调大到10-20秒避免把短暂的GC和抖动误判成宕机。并且每个季度做一次故障演练故意模拟分区验证配置是否真的能兜住。这种事演练的时候丢数据总比上线丢数据好得多。
