Redis集群复制机制详解：全量同步、增量同步与故障转移

1. 为什么面试官总揪着集群复制机制不放面试Redis相关岗位十次有七八次绕不开集群复制机制。不是面试官故意找麻烦而是复制这层逻辑几乎撑起了整个集群的可靠性数据在节点间怎么流动、主库挂了从库能不能顶上、切换之后会不会丢数据全部压在这条复制链路上。你光会set key value和背几道缓存穿透的题在集群这块根本扛不住追问。Redis Cluster 本身解决的是数据分片和高可用的问题而高可用必须依赖复制每个主节点背后至少要挂一个从节点主节点写从节点同步主节点真挂了从节点才有资格顶上去。这句话大家都会说但面试官想听的是机制层面的东西——全量同步和增量同步分别发生在什么时机复制偏移量是怎么计算的断线重连时怎么判断能不能接着上次的位置续传故障转移时数据到底会不会丢。能把这些讲清楚才算真正理解了集群复制。这篇文章就是照着这个思路写的。适合三类人看正在准备Redis面试的人做架构选型时纠结集群方案的人以及集群已经跑起来但偶尔遇到主从数据对不上想搞清楚排查链路的人。内容不会停留在术语层面尽量把每个机制的因果逻辑和实操注意点都说透。1.1 高可用不是“备份”那么简单很多人把复制当成“实时备份”这个理解偏差很大。备份的意义是误删了能恢复而Redis复制的核心价值是让另一个节点拥有与主节点几乎相同的数据以便在主节点故障时对外继续提供服务。它解决的是可用性问题捎带解决了读扩展问题。但“几乎相同”这四个字非常关键因为它暗示了复制不是强一致的。Redis集群的复制默认是异步的主节点写完命令后直接返回客户端成功不会等从节点确认。从节点同步数据存在天然延迟延迟期间主从数据就是不一致的。面试题里常见的“刚写入就读从库结果读不到”就是在这个背景下产生的。明白了这一点你就会发现复制机制的设计本质上是在一致性、可用性、性能之间做取舍。理解了取舍后面所有细节才有意义。1.2 面试官真正想听的不是背定义如果你去背“异步复制、全量同步、增量同步、复制积压缓冲区”这些名词面试官再追问两层就会露馅。真正的考察点是你知道主从之间是怎么建立复制关系的吗你知道一次全量同步会经历哪些阶段瓶颈在哪里你知道什么情况下只能全量同步什么情况下可以增量续传你能说出复制延迟的常见原因并且给出排查命令吗你能讲清楚故障转移时为什么从节点越接近主节点越不容易丢数据吗这些问题没有一个能靠背定义应付过去。它们要求你把复制机制当成一条完整的数据流水线来理解而不是拆成孤立的几个知识点。接下来我们就按这套逻辑从复制链路的结构讲到同步流程再讲到故障转移和实操排查。2. 集群复制链路拆解主从视角、槽位视角、消息视角2.1 Cluster 和普通主从复制不是两套机制很多人有一个误区觉得Redis Cluster的复制和普通的主从复制是两套互不相干的机制。实际上Cluster并没有发明一套新的复制协议它仍然是每个主节点照着标准的REPLICAOF方式去挂从节点复制数据流、RDB传输、命令传播这些底层逻辑完全一样。区别在于Cluster多了一层槽位管理。整个集群有16384个哈希槽这些槽被分散到各个主节点上。写入一个key时客户端或代理会先通过CRC16算法算出这个key落在哪个槽再找到拥有这个槽的主节点。从节点的任务不是自己分配槽位而是负责完整复制主节点的数据。换句话说主节点上有哪些槽从节点就备份哪些槽的数据。这样设计有一个直接后果从节点在正常状态下是不承担客户端读写请求的。虽然从节点手里有完整的数据副本但Cluster模式下如果你不显式发送READONLY命令就向从节点发请求多半会收到一条MOVED重定向让你去找对应槽的主节点。这个行为看起来有点“浪费从节点”但它保证了槽位归属和读写路径的清晰性避免了客户端数据写到了从节点、主节点又不知道的混乱情况。2.2 复制链路中哪些角色在干活一条完整的复制链路里有几个角色值得我们记住主节点负责执行写命令维护复制偏移量和积压缓冲区向从节点推送数据。从节点负责接收复制流加载RDB或应用增量命令维护自己的复制偏移量。复制积压缓冲区主节点内存中的一块环形缓冲区保存最近传播的写命令是实现部分重同步的关键。偏移量主节点有一个master_repl_offset每个从节点有一个slave_repl_offset它们记录的是已传播/已应用的数据字节位置。主节点处理写命令时并不是先写一个“复制日志”再单独发出去而是把命令追加到积压缓冲区后异步发送给所有从节点。这个发送动作由主节点的事件循环负责不阻塞主线程处理新的客户端请求。这种设计保证了复制的高性能但也带来了延迟和丢数据的可能。2.3 数据从主库到从库的路径想象一下客户端在主节点上执行了一条SET user:1001 name tom。主节点做了三件事执行内存写入、记录AOF如果开启、把这条命令写进复制积压缓冲区并排入从节点的输出缓冲区。从节点通过长连接拿到命令后在自己的内存里执行同样的写入并把自己的偏移量更新到对应位置。这条路径看起来简单但每一步都可能成为瓶颈。主节点的输出缓冲区如果太小或者网络带宽不足命令就会堆积在从节点侧从节点如果正在处理慢查询或者执行数据集加载也会拖慢复制进度。后面讨论复制延迟时这些环节都会再次出现。3. 一次全量同步的全过程从握手到RDB传输3.1 什么时候触发全量同步全量同步的行话叫“full sync”字面意思就是主节点把整个数据集的RDB快照发给从节点。这种操作很重会带来网络和磁盘开销所以不是常态。触发场景主要有三类从节点第一次与主节点建立复制关系。从节点断线时间太长主节点的复制积压缓冲区里已经没有从节点需要的偏移量。主节点重启导致run_id变化从节点无法基于旧run_id做增量续传。面试时容易漏掉的是第三种场景。主节点的run_id是每次启动时随机生成的唯一标识复制关系会把它绑定到从节点身上。如果主节点重启了从节点虽然还连着同一个IP但run_id对不上PSYNC协议会直接判定无法继续增量同步被迫全量重传。所以生产环境里最忌讳频繁重启主节点尤其挂了很多从节点的时候一次重启可能引发所有从节点同时全量同步网络瞬间被打满。3.2 全量同步的完整流程全量同步不只传输一份RDB那么简单它是一套“边拍摄边发车”的流程。我看到的完整过程是这样的从节点向主节点发送PSYNC ? -1表示自己没有任何复制历史请求全量同步。主节点收到后返回FULLRESYNC run_id offset告诉从节点主节点的身份标识和当前偏移量。主节点触发一次BGSAVE在后台fork子进程生成RDB快照。这个fork动作是内存级别的Linux下使用了写时复制所以瞬间开销不大但如果实例很大fork瞬间也可能卡住主线程几百毫秒。在RDB生成期间主节点仍然正常处理写命令所有新写入都会被保存到复制积压缓冲区和从节点的输出缓冲区。RDB生成完成后主节点把RDB文件发送给从节点。从节点收到RDB后先清空自己的旧数据然后加载RDB文件把自己“重置”到主节点生成快照那一刻的数据状态。RDB加载完成后主节点把缓冲区内攒下的增量命令继续传给从节点从节点追上主节点的最新偏移量。从节点的清空和加载过程是阻塞的加载期间从节点无法对外提供服务虽然正常情况下客户端也不会直接打到从节点。RDB文件越大这个窗口越长。如果集群里同时有多个从节点第一次接入就会出现“复制风暴”主节点要fork多次、传多份RDB压力肉眼可见地往上走。3.3 控制全量同步开销的配置生产环境里全量同步无法完全避免但可以把它控制在一定范围内。几个关键配置值得记在脑子里配置项作用实践建议repl-diskless-sync是否启用无盘复制RDB直接通过网络发送不落主节点磁盘从节点多且网络可靠时可以打开减少磁盘IOrepl-diskless-sync-delay无盘复制模式下等待多个从节点一起同步的延迟秒数默认5秒能降低多次fork的CPU开销client-output-buffer-limit replica限制主节点发送给从节点的输出缓冲区大小设置过小会导致大实例全量同步被强制断开repl-timeout主从节点之间的超时时间网络抖动大的环境适当调大默认60秒我见过一次比较典型的坑某同学给一个几十GB的实例挂从节点默认配置没改结果传输RDB期间从节点输出缓冲区超过了默认的client-output-buffer-limit replica 256mb 64mb 60主节点直接把连接断掉从节点又发起重连陷入“全量同步—断连—再全量同步”的死循环。解决办法很简单要么调大这个缓冲上限要么开启无盘复制并错开同步时间。4. 断线重连与增量同步复制积压缓冲区是命根子4.1 偏移量复制链路的“水位线”全量同步解决的是“从零开始”的问题但生产环境里更常见的是从节点短暂断网、主从连接闪断这种场景如果用全量同步就太浪费了。Redis的解法是让主节点在内存里维护一个复制积压缓冲区同时用偏移量记录数据流的位置。主节点每传播一条命令就追加到积压缓冲区并把master_repl_offset往后推。从节点每应用一条命令也把自己的slave_repl_offset往后推。正常情况下两个偏移量之差能反映出主从复制积压了多少数据。断线期间从节点不再接收数据所以从节点的偏移量停留在断线前的某个位置主节点继续写入偏移量不断前进。重连时从节点只需要告诉主节点我的run_id和偏移量是这个。主节点一看从节点需要的偏移量还在自己的积压缓冲区里并且run_id也对得上就直接回复CONTINUE把从偏移量开始的那段增量命令重新传给从节点。这个过程叫部分重同步也就是增量同步。4.2 PSYNC 如何决定增量还是全量PSYNC的决策逻辑并不复杂核心看两样东西主节点当前的run_id和从节点记录的run_id是否一致。从节点请求的偏移量是否仍然落在主节点积压缓冲区的有效范围内。如果run_id不一致说明对面已经不是原来那个主节点了之前的偏移量没有参考意义只能全量。如果run_id一致但偏移量太老已经被积压缓冲区覆盖了也说明主节点这边找不到历史位置只能全量。所以积压缓冲区的大小直接决定了增量同步的容错范围。缓冲区越大能容忍的断线时间越长但内存占用也越高缓冲区越小稍微断一会儿网就触发全量同步。这是典型的拿内存换带宽的权衡。4.3 积压缓冲区到底该设多大这个问题面试概率极高。直接给公式repl-backlog-size至少要大于峰值写入速率 × 期望容忍的断线时间。举个例子一个主节点高峰期每秒写入约50MB数据如果希望从节点断线60秒后重连仍然能做增量同步那缓冲区至少要留50MB × 60s 3000MB的余量。再加上故障检测、选举、重连本身也要时间再乘以1.5到2的系数设置6GB左右比较稳妥。如果带宽和内存有限至少要保证在网络抖动最频繁的那段时间内不触发全量。还有一点容易被忽略积压缓冲区是主节点内存里的环形缓冲它的大小不会因为心跳、读请求、过期键清理而变化只有写命令传播才会推进偏移量。因此判断该调多大时要重点看主节点的写流量峰值而不是总内存量。5. 复制延迟、脑裂与数据丢失集群的命门在哪5.1 复制延迟是怎么冒出来的复制延迟最直观的体现就是从节点偏移量落后主节点多少字节以及换算成时间大约落后多久。查看方式很简单在从节点上执行INFO replication看master_repl_offset和slave_repl_offset的差值。常见的延迟原因有几种主节点和从节点跨机房甚至跨地域部署网络往返时间本身就高写流量瞬时暴涨单线程的主节点处理不过来发送命令的节奏自然变慢某些大key的写入导致一条命令体积很大传输耗时显著增加从节点自身执行较慢比如正在做过期键的惰性删除或者内存碎片整理占用CPU。排查延迟时不要只盯着网络看先确认主节点CPU是否被打满再从INFO stats里看total_net_input_bytes和total_net_output_bytes的增速是否异常。大部分延迟问题都能在这两步里找到线索。5.2 脑裂场景下哪部分数据会丢脑裂指的是网络分区情况下原主节点和集群其他节点失去联系但它自己并不知道仍然继续接收客户端写入另一边集群检测到主节点失联后把某个从节点提升为新主节点。等分区恢复原地主节点发现自己已经被替代只能降级为从节点重新向新主节点同步。而这个过程中它独自写入的数据会因为新主节点那边没有这些数据而全部被丢弃。这不是Redis的bug而是异步复制的机制所决定的。复制是往后传的只要数据还在原主节点内存里没来得及发给从节点一旦发生故障转移这部分数据就处于“将要丢失”的状态。任何声称Redis集群能保证不丢数据的说法严格来讲都不准确除非你搭配了额外的数据持久化或同步复制手段。5.3 用 min-replicas 和 WAIT 换取安全如果你对丢数据零容忍又不能改成全同步复制可以用折中方案让主节点在从节点不够健康的时候拒绝写入。相关配置是min-replicas-to-write和min-replicas-max-lag。假设设置min-replicas-to-write 1min-replicas-max-lag 10含义是主节点至少要有一个从节点并且这个从节点最近一次复制心跳延迟不超过10秒否则主节点拒绝处理写请求。这样做的代价很明显如果唯一的从节点也挂了整个主节点直接变成只读牺牲可用性换取数据安全。WAIT命令则是另一种粒度。写命令执行后可以WAIT 1 0阻塞等待至少1个从节点确认收到这条命令再返回。注意这里强调的是从节点“收到”并记录到了自己的复制流中不等同于从节点事务已经提交并落盘。但对很多业务来说这已经足够缓解“写后读不到”的问题。6. 故障转移时复制的表现选举、重连、角色切换6.1 从节点竞选新主的大致过程集群里某个主节点失联后它的从节点不会立刻抢着上位而是先进入候选状态向集群中其他主节点发起故障转移选举。Redis Cluster的选举机制参考了Raft的思想每个从节点根据复制偏移量计算延迟分数越接近主节点数据的从节点优先级越高优先发起选举请求其他主节点会在一个配置纪元内给合资格的从节点投票。从节点要成为新主需要拿到多数主节点的赞成票。票数通过后从节点把自己切换成主节点接管原主节点的哈希槽随后在集群内广播自己已经成为槽位的新归属节点。这个过程通常只需要几秒钟但前提是集群能及时完成故障判定并且有足够的主节点在线参与投票。如果在故障期间原主节点实际上只是网络分区并没有宕机那么它会在分区恢复后发现自己已经被降级。集群会要求它变成新主节点的手下作为从节点重新复制数据。刚才提到的那部分丢失数据就发生在这个重新复制的过程中。6.2 原主恢复后如何回归原主恢复后的行为值得单独说。它不会自动恢复成主节点而是以从节点身份接入集群去复制新主节点。新主节点此时已经接管了它之前的槽位所以原主需要先清空自己内存中孤立的数据再通过PSYNC接收新主的复制流。这里有个常见问题如果原主断线期间写入的数据量很大而新主积压缓冲区又很小原主降级后的同步就可能直接退化成全量同步。全量同步期间原主会短暂阻塞导致这块区域的数据访问延迟明显升高。因此生产上做故障恢复演练时最好提前把repl-backlog-size调大给原主回归留够增量同步的余地。6.3 手动切换时别忽略复制偏移量除了自动故障转移Redis Cluster还支持手动切换也就是执行CLUSTER FAILOVER。这个命令通常在需要升级主节点、腾挪内存或把流量从节点迁移时使用。手动切换的好处是正常情况下从节点先尽力追平主节点的偏移量等两边数据基本对齐后再发起角色切换丢失数据的窗口被压得非常小。但要注意CLUSTER FAILOVER FORCE和CLUSTER FAILOVER TAKEOVER这两种变形。FORCE会跳过一些前置校验可能在你数据还没追平时就强行切换TAKEOVER则更直接它完全不依赖其他主节点的投票直接从一个任意偏移量位置接管槽位。这两种方式都属于“应急操作”尤其是TAKEOVER数据丢失风险高除非有明确理由和补偿方案否则不要在生产环境里乱用。7. 面试高频追问与日常排查工具箱7.1 五个追问可以直接拿来练面试官很少直接让你背概念他们更愿意把问题包装成场景。下面是几个高频追问以及建议的回答方向追问建议回答方向主从复制时主节点挂了数据会丢吗会丢因为复制是异步的主节点未同步到从节点的数据在切换后无法找回。从节点接收的RDB和增量命令会不会把主节点的AOF也复制过来不会复制只传数据和命令不复制AOF文件本身从节点可以自行开启或关闭AOF。全量同步时主节点还能继续处理写请求吗能会fork子进程生成RDB新写入的命令先积压在缓冲区和输出缓冲区里。复制延迟很大第一个要看什么指标先看INFO replication里的偏移量差值再看主节点输出的网络字节速率和CPU占用。为什么主节点重启一般会造成多个从节点全量同步因为重启后 run_id 变化从节点无法基于旧 run_id 做增量续传。7.2 排查复制问题的常用命令真正在集群上排查问题时命令不一定多但要看对地方INFO replication看主从角色、偏移量、复制连接状态。INFO stats关注sync_full、sync_partial_ok、sync_partial_err这三个计数能直接反映增量同步的成功率和失败次数。CLUSTER NODES看节点角色、槽位分布、连接状态。CONFIG GET repl-backlog-size确认积压缓冲区设置。redis-cli --latency测客户端到节点的网络延迟但注意这不能完全代表复制延迟。如果发现sync_partial_err持续增长基本可以断定从节点经常带着过期偏移量重连优先怀疑积压缓冲区设置偏小。如果主节点repl_backlog_active是0则说明缓冲区没有启用或者当前没有从节点在复制这个状态也值得留意。7.3 我踩过的三个复制“小坑”第一个坑和大key有关。某次主节点执行了一条批量写入把一个大哈希结构一次性写了几十MB整个复制流瞬间飙升从节点的偏移量差距在几秒钟内拉得非常大。后来查下来不是网络带宽不够而是这条大命令在从节点上应用时非常耗时期间新的写命令继续堆积延迟迟迟追不平。从那以后我就养成了习惯对超大hash和list做分片写入避免单条命令体积过大。第二个坑是同时给一个忙得不可开交的主节点挂多个从节点。操作时看起来只是添加节点实际上每个新从节点都会触发全量同步主节点要在短时间内生成多份RDB、传多份全量数据网络和磁盘双双被打满。后来我先用无盘复制再把添加从节点的操作错开时间才把这个冲击按下来。第三个坑是低估了故障检测和重连的时间。我算积压缓冲区大小时只算了从节点断线那几十秒的写入量忘了把集群标记主节点失败、发起选举、从节点执行切换这一整套流程的时间也算进去。结果真发生一次网络闪断时从节点重连后偏移量已经超出缓冲区范围被迫全量同步。从那以后缓冲区大小的计算我会额外加上至少一倍余量。复制机制看着知识点很多但只要抓住“偏移量往哪走、缓冲区能兜多大、异步复制丢哪段数据”这三条主线整个体系就串起来了。面试和实战都是同一个道理。