Redis同步机制详解：主从复制与全量/增量同步核心原理

从面试官的角度来看Redis同步机制几乎是每次必聊的话题。不管是初级岗位问主从复制还是高级岗位聊集群数据一致性绕来绕去始终离不开同步这两个字。很多同学背了Redis命令、看过源码解析但一到现场让他讲讲从节点怎么追上主节点进度就开始含糊了。这篇文章不打算从源码逐行分析而是把Redis同步机制这条线完整捋一遍主从复制为什么存在、全量同步和增量同步分别走什么流程、日常运维会踩哪些坑、面试官到底在考你什么。不管你是准备跳槽还是正在维护一套生产环境的Redis这篇文章都值得看完。1. Redis同步机制到底在解决什么问题1.1 从单机到主从同步需求从哪来Redis作为内存数据库单机部署最大的隐患就是挂了就没了。虽然配置了AOF和RDB持久化数据可以恢复到磁盘上的状态但恢复期间整个服务是不可用的。对线上业务来说这几十秒甚至几分钟的空白期可能就是事故。于是就有了主从架构。一台主节点负责写若干从节点负责同步数据并提供读服务。主节点挂掉的时候从节点可以顶上来这就是Redis高可用最基本的一环。而这个架构能成立的前提就是主从之间必须有一套可靠的同步机制把数据从主节点搬运到从节点。注意我用的词是搬运但实际上同步机制要解决的远不止拷贝一份数据这么简单。主节点是持续接收写请求的也就是说同步是一个动态过程从节点不仅要拿到某一时刻的全量数据快照还要持续跟上主节点后续产生的每一次写入。这就是为什么Redis的同步机制被设计成全量同步增量同步组合的原因。1.2 同步机制承担的三类核心职责先想清楚同步机制到底扛了哪些事情后面看原理就不会乱。第一是数据冗余。这是最直接的主节点上的数据在从节点上有完整副本单台机器磁盘损坏不会导致数据全丢。第二是读写分离把读流量分摊到多个从节点上让主节点专心处理写请求。第三是高可用切换的基础哨兵和集群在做故障转移的时候需要选举从节点晋升为新的主节点而晋升的前提就是这个从节点的数据不能落后主节点太多。这三件事层层递进但底子都是同一个东西主从之间数据的一致性。面试官问同步机制本质就是在考察你对一致性这个分布式系统核心概念的理解深度。1.3 同步机制的两代演进早期Redis版本用的同步命令是SYNC实现方式非常简单粗暴从节点连上主节点主节点执行BGSAVE生成RDB快照然后把RDB文件一股脑发给从节点从节点清空自己的数据再加载这份快照。问题在于即使从节点只是断开了几秒钟重连后依然要触发全量同步RDB文件多大就传多大在数据量上G的情况下非常浪费资源。所以从Redis 2.8开始引入了PSYNC命令支持部分同步。核心改进是引入了复制积压缓冲区、复制偏移量和主节点的Replication ID。当从节点重连时主节点先判断从节点缺失的数据是否还在缓冲区里如果在只需要把缺失的那段命令发给从节点补上即可。到了Redis 4.0以上PSYNC又升级了引入了PSYNC 2解决了从节点提升为主节点后其他从节点要重新全量同步的问题。这个演进过程恰恰是面试最喜欢考的地方你不仅要说出SYNC和PSYNC的差别还要能解释为什么每个版本要做这种改进。2. 主从复制的核心原理拆解2.1 全量同步第一次见面就拷贝家底当一个从节点第一次连接主节点或者重连后数据差距太大时就会触发全量同步。整条链路按顺序大概是下面这样。从节点向主节点发送PSYNC ? -1意思是我不知道你的运行ID也不知道自己的复制偏移量给我来一次全量吧。主节点收到后开始执行BGSAVE在后台生成一份RDB快照文件。与此同时主节点会把从节点连接建立之后收到的所有写命令写入复制积压缓冲区并缓存下来——这一步非常关键后面细说。RDB生成完毕主节点把它发送给从节点。从节点拿到文件后首先清空自己内存里的旧数据然后加载RDB文件。加载完成后从节点在数据层面就和主节点生成快照那一刻保持一致了。但问题是从生成快照到从节点加载完快照这段时间主节点又接收了大量新的写请求。所以RDB加载完毕后主节点会把复制积压缓冲区里缓存的写命令继续发送给从节点。从节点一条条执行这些命令最终追上主节点的最新状态。这里面有四个细节特别容易踩坑。第一个从节点在清空旧数据并加载RDB的整个过程中是阻塞的不能响应客户端请求。数据量越大阻塞时间越长。第二个主节点执行BGSAVE期间会对磁盘有较大IO压力如果同时有好几个从节点触发全量同步主节点可能扛不住。第三个RDB传输过程非常消耗主节点带宽跨机房复制的时候尤其明显。第四个从节点加载完RDB之后并不是立刻就能赶上主节点中间追赶写命令的过程如果积压缓冲区被覆盖了会再次触发全量复制形成恶性循环。2.2 增量同步断点续传的设计思路增量同步解决的是从节点短暂断线后的数据补齐问题。从节点重连后会发送PSYNC replid offset携带两个关键参数它记住的主节点运行ID以及它自己当前的复制偏移量。主节点收到后先比对运行ID。如果对不上说明从节点之前连接的是别的主节点数据来源都变了直接退化成全量同步。如果运行ID对得上再看偏移量对应的数据是否还在复制积压缓冲区里。复制积压缓冲区是一个固定大小的环形缓冲区默认1MB主节点近期执行的写命令都会写入这里。如果从节点的偏移量落在缓冲区未覆盖的范围内主节点就回复CONTINUE然后把从offset1开始到最新位置的命令数据一次性发给从节点。要是从节点断线时间太长偏移量对应的数据已经被环形缓冲区覆盖掉了主节点就无能为力了只能再次全量同步。我自己生产环境里的经验是1MB的默认缓冲区在写入量比较大的场景下完全不够用。假设你的业务高峰期每秒写入1000次每次命令大约100字节一秒钟就是100KB1MB缓冲区十秒钟就被覆盖掉了。哪怕从节点只是断线半分钟重连后都只能全量同步。所以复制积压缓冲区的大小一定要根据业务写入量来算。2.3 复制偏移量与心跳机制复制偏移量是主从节点各自维护的一个计数器。主节点每向从节点发送N字节数据就把自己的master_repl_offset增加N从节点每接收并执行N字节数据就把自己的slave_repl_offset增加N。正常情况下这两个值保持一致就算有差距也是主从之间正在传输的极小部分。心跳机制保证主从双方能感知彼此存活。从节点默认每隔1秒向主节点发送一次REPLCONF ACK命令顺便上报自己的复制偏移量。主节点收到后会更新该从节点最近一次通信的时间。如果超过repl-timeout配置的时间默认60秒没有收到从节点的任何心跳主节点就认为从节点已经断线了会在info replication里把这个从节点的状态标记为disconnected。这里有个面试官特别喜欢挖的细节心跳不只是保活探测从节点上报偏移量的动作实际上是在告诉主节点我已经执行到哪儿了主节点可以根据这个信息判断是否发送增量还是触发全量。所以说同步机制并不是主节点单向推送而是一个双向配合的过程。2.4 从节点重启后的同步策略从节点重启之后它内存里的数据全部丢失但磁盘上的RDB/AOF文件还在所以启动后可以恢复之前的数据。关键问题是重启期间主节点产生了新的写入这部分数据怎么补这就用到刚才说的复制偏移量机制。从节点持久化的时候会把当前的主节点运行ID和复制偏移量记录下来。重启之后从节点加载本地持久化文件然后发送PSYNC replid offset给主节点。如果主节点判断offset还在积压缓冲区内就只需要增量同步缺失的部分。Redis 4.0之后引入的PSYNC 2还有一个重要改进。当一台从节点被晋升为主节点后其他从节点不需要全量同步而是通过新的运行ID和旧的运行ID之间的关联关系继续复用之前的主从复制链路。这个改进在生产环境故障切换的时候帮了大忙没有它的话每次哨兵切换主节点所有从节点都要重新全量同步一遍那个数据量在大型集群里是灾难级的。3. 动手实操从零搭建一套主从同步环境3.1 准备工作与Redis安装要说清楚原理不如自己动手跑一遍。先在本地准备两台装好Redis的机器或者干脆在单机上用两个不同端口模拟。生产环境最常见的部署方式是Docker Compose起一主两从我建议你直接照着这个方式试后面清理环境也方便。如果你用的是Linux服务器安装Redis非常简单。Ubuntu系可以用apt install redis-serverCentOS系用yum install redis。也可以从官网下载源码包编译安装方式无所谓。关键是装完之后确认版本号在5.0以上因为早期版本在部分同步和集群管理上特性差很多有些坑你已经没必要踩了。我用Docker Compose演示一主两从的部署。创建目录后先写一个docker-compose.yml定义三个服务。这里有个细节Docker里运行Redis默认不会加载外部配置文件要么挂载配置文件要么在启动命令里直接传参数。图省事的话直接在command里覆盖配置最直观。version: 3.8 services: redis-master: image: redis:7.0 container_name: redis-master ports: - 6379:6379 command: [redis-server, --appendonly, yes, --repl-backlog-size, 64mb] redis-slave1: image: redis:7.0 container_name: redis-slave1 ports: - 6380:6379 command: [redis-server, --appendonly, yes, --replicaof, redis-master, 6379] redis-slave2: image: redis:7.0 container_name: redis-slave2 ports: - 6381:6379 command: [redis-server, --appendonly, yes, --replicaof, redis-master, 6379]执行docker compose up -d三台Redis就起来了。这个配置文件里有两个关键点值得说说。3.2 主节点参数配置说明从Redis 5.0开始原来的slaveof配置项改名成了replicaof命令层面的SLAVEOF也被REPLICAOF取代。虽然旧的配置在兼容模式下还能用但新环境里建议直接使用新命名。我在上面把主节点的复制积压缓冲区设置成了64MB这是根据业务写入速率算出来的。前面提到过默认的1MB很容易在写入量稍微大一点的情况下被覆盖。但对于单机模拟来说64MB其实偏大生产环境要根据实际写入速率和可接受的全量复制频率来推算公式大概是这样建议值 主节点平均每秒写入量 × 从节点最大可能断线秒数 × 1.5的安全系数。主节点还可以配置repl-diskless-sync默认是no。如果你环境里的磁盘性能较差而网络带宽充足可以开启无盘复制。开启后主节点不会把RDB写入磁盘而是直接在内存中把RDB快照通过网络socket传输给从节点。这是我踩过一次的坑某次在IO延迟很高的云盘上做主从全量同步时主节点IO直接被打满业务接口平均延迟飙升到几秒。后来开启了无盘复制情况立刻好转。3.3 从节点配置说明从节点的核心配置就是一行replicaof masterip masterport。有一个参数我建议你在生产环境务必关注replica-read-only默认就是yes表示从节点只接受读请求。这个默认值千万别改一旦把从节点改成可写业务代码不小心往从节点写了数据就会造成主从不一致而且这个不一致没有任何机制会自动修复想要矫正只能重建从节点。还有replica-serve-stale-data参数默认是yes。这意味着当从节点与主节点的连接断开或正在进行全量同步时从节点依然可以响应旧的读数据。如果你的业务对数据一致性要求很高可以把这个参数设成no让从节点断连期间直接返回错误避免客户端读到明显过期的数据。从节点的repl-backlog-size其实不用单独设置因为从节点自己维护的积压缓冲区主要是用于对接替主节点时给新从节点提供增量同步。但如果你的从节点可能晋升为主节点建议还是把它调到和主节点一样的水平。3.4 验证主从同步状态启动容器后进入主节点查看复制状态docker exec -it redis-master redis-cli info replication正常情况下输出里会有一大段Replication相关的信息。重点是这几个字段connected_slaves应该显示为2每个从节点的state应该是onlinelag字段是每个从节点在心跳间隔内的延迟秒数正常应该在0到1之间。docker exec -it redis-slave1 redis-cli info replication从节点上查看时关注master_link_status是不是up以及slave_repl_offset是否和主节点的master_repl_offset保持同步。如果你在主节点写入数据几毫秒后再去从节点读应该马上就能读到这就是同步机制实时生效的结果。实际操作验证时我会故意在主节点写一个大字符串然后在从节点上观测复制延迟。看到lag始终为0说明主从之间的管道是畅通的。3.5 故障演练模拟从节点断线重连这个实验非常直观。先从主节点写入一批数据然后暂停从节点容器再继续写一批接着把从节点容器恢复。恢复后观察日志你会看到从节点发送PSYNC请求然后从主节点获取断线期间缺失的命令。但注意如果你断线时间足够长长到主节点积压缓冲区已经被新写入覆盖恢复后就会看到日志里出现全量同步的字样。我在测试环境特意试过一次往主节点疯狂写入几十万条数据后再恢复从节点果然触发了BGSAVE和RDB传输。这就是为什么前面强调要把积压缓冲区调大的原因——它能撑住多长时间的断线重连决定了你要不要承受一次全量同步的资源开销。4. 面试必考点高频问题与排查技巧实录4.1 主从数据延迟问题怎么排查面试官最常见的追问是如果从节点数据一直追不上主节点你觉得可能是什么原因这个问题特别考验实战经验因为原因可能出在多个层级。网络层是最容易排查的。跨机房复制如果机房之间网络抖动从节点发送的心跳和ACK就会延迟主从之间的偏移量差距会被拉大。这个看info replication里的lag就能判断如果lag长期大于1甚至不断上升优先检查网络连接质量。命令执行层有一个隐蔽的坑慢查询。主节点发送过来的写命令在从节点落地执行如果某条命令在从节点上执行时间过长比如对一个大key执行SORT或KEYS操作或者写入一个超大集合后续命令就会排队堆积造成复制延迟。排查方式是查看从节点的慢查询日志定位那些执行时间超过阈值的命令。还有一个经常被忽略的原因是主节点本身有大量key在同时过期。过期key的删除操作也会进入复制流主节点删除一批key从节点也要同步删除。如果大量key在同一秒到达过期时间从节点处理这些删除命令的瞬间就会出现延迟尖峰。4.2 全量复制风暴如何避免所谓复制风暴就是网络里同时出现多台从节点请求全量同步导致主节点IO和网络带宽瞬间被打满。这个场景最典型的发生时机是主节点重启之后所有从节点同时尝试重连并请求同步。避免复制风暴的思路是错峰和分级。首先把从节点的repl-backlog-size调大减少全量同步的触发概率。其次让部分从节点不要直接挂主节点而是挂到其他从节点下面形成树状结构。主节点只需要给一台从节点提供全量同步其他从节点从下一级获取数据这样主节点的压力会小很多。这个架构在从节点数量超过十台以上的时候几乎是必须的。还有一个实际的心得尽量避免在业务高峰期重启主节点。如果不得不重启先摘掉一个从节点作为备用主节点等主节点恢复正常后再重新挂载比让所有从节点同时重连要安全得多。4.3 复制积压缓冲区大小应该怎么设这个问题我前面反复提过因为它在面试中出现频率极高。面试官问法通常是你们生产环境下repl-backlog-size设置的是多少为什么答案不是一个固定值而是一个推导过程。先统计业务高峰期主节点的写入速率假设是每秒2MB再确定你希望从节点最多断线多久后还能走增量同步假设是5分钟也就是300秒。那么积压缓冲区至少需要600MB再乘以1.5的系数留出余量建议设置900MB左右。但有一点要明白积压缓冲区占用的是主节点的内存设置的越大可用内存就越少。所以实际配置是在内存代价和全量同步频率之间做权衡。如果一台主节点内存本来就紧张建议优先把从节点断线时间缩短而不是无脑调大缓冲区。4.4 主从复制和持久化配置的关系面试官还爱问的一个问题是如果主节点关闭了持久化会有什么风险这个问题坑特别多。如果你在主节点上把save规则全禁用且没开AOF那么主节点一旦宕机重启内存里是空数据。此时从节点发现连接断开会不断尝试重连主节点。等主节点起来后从节点发现主节点数据是空的就会触发全量同步把空数据同步过来。结果是整个主从结构里的数据全被清空这在生产环境是重大事故。所以生产环境的主节点绝对不能关闭持久化。如果出于性能考虑想减少持久化对主节点的影响至少要在从节点上开启持久化并且把主节点的AOF打开。安全底线是任何一台Redis节点都必须开启至少一种持久化方式。4.5 从节点过期键删除机制这个点属于进阶考点。Redis的key过期策略是惰性删除加定期删除主节点在发现key过期并执行删除时会把这个删除操作通过DEL命令同步给从节点。看起来没问题但有一个边界场景从节点在响应读请求时遇到一个已经过期但还没被主节点删除的key它并不会主动删除而会返回空值。更隐蔽的问题是从节点不会自己执行过期删除它只听从主节点的DEL命令。如果主节点因为某种原因长时间没有触发删除比如key访问频率很低惰性删除一直没轮到它那么从节点上对应的过期key就会一直存在。对于读写分离的业务来说客户端可能就在从节点上读到这个已经过期的数据。解决的思路是在从节点上也开启activedefrag并配合合理的maxmemory-policy或者接受这种最终一致性场景下极小概率的过期读问题。5. 同步机制在哨兵与集群场景下的变化5.1 哨兵模式下的主从切换单看主从复制还不足以应对生产环境的高可用需求因为主节点挂了从节点不会自动顶上。哨兵就是干这件事的监控、通知、自动故障转移。哨兵模式下主节点宕机后哨兵集群会选出一台从节点提升为新主节点。这个过程里同步机制扮演的角色非常有意思。晋升的从节点需要把replicaof配置清除变成新的主节点其他从节点则要重新指向新主节点发起同步。这里有一个性能瓶颈其他从节点收到新主节点的同步请求后如果PSYNC的runid对不上就会退化成全量同步。Redis 4.0以后通过主从复制链路上的replid2机制从节点切换主节点时可以复用之前的复制历史避免全量同步。但即便如此切换期间的写命令还是存在短暂丢失的可能因为旧主节点宕机那一刻有些命令已经写入旧主节点但还没同步给任何从节点。5.2 Redis Cluster的同步与主从复制Redis Cluster采用了分片架构数据按照CRC16哈希算法分到16384个slot上每个节点负责一部分slot。但集群的每个分片内部依然是一组主从结构在兜底。集群模式下的同步机制和普通主从复制本质相同普通节点之间用PSYNC进行同步只是多了一层Cluster bus用来交换节点状态信息。集群的消息传递走的是另外一个端口节点之间通过Gossip协议互相交换状态选举主节点时用的也是这套机制。集群模式下有一个和同步机制强相关的问题网络分区。当集群中某个主节点和它的从节点被分区隔离时集群可能处于fail状态需要等待超过半数的主节点选举出新的主节点。这个场景下同步数据的一致性保证是尽力而为的会丢失少量未同步的写操作。5.3 同步机制的可靠性边界你会丢多少数据面试谈到最后面试官通常会抛出那个灵魂问题Redis主从同步到底会丢数据吗答案是会但不是在所有场景下。在主-从模式且没有开启wait命令的情况下主节点只要本地写成功就会返回客户端ACK从节点是否收到完全取决于网络。如果主节点在把命令发给从节点之前宕机这条命令就丢了。全量同步场景下如果RDB传输完成但加载之前从节点宕机数据同样会丢失。想要减少这些丢失场景可以开启Redis的WAIT命令机制让主节点等待至少N个从节点的ACK后才返回写成功代价是写延迟显著增加。这本质上就是分布式系统里经典的CAP权衡追求强一致性就牺牲可用性和性能追求高可用和高性能就必须接受极端场景下的少量数据丢失。6. 常见问题与故障排查速查表6.1 主从同步常见异常整理我把自己维护Redis过程中遇到过的同步异常整理成了一个速查表面试或排障的时候直接对照着看。异常现象可能原因排查手段从节点状态一直handshake主节点密码不一致检查requirepass和masterauth配置lag值持续增长网络延迟或存在大key慢查询检查网络丢包和slowlog从节点反复全量同步积压缓冲区过小调大repl-backlog-size并重启从节点主节点磁盘IO飙高多个从节点同时触发全量同步错峰挂载或开无盘复制从节点数据与主节点不一致从节点被误设为可写禁止运行时修改replica-read-only重启从节点后大量丢key本地持久化未开启确认appendonly yes6.2 排查同步问题的方法论如果从节点复制出错第一步永远是查看日志。Redis的日志会明确告诉你同步失败到哪一步了是连接不上主节点还是RDB传输中断还是命令应用失败。第二步是看info replication的输出对比主从的offset差距。第三步是检查主从之间的网络质量用redis-cli --latency实测一下往返延迟。有一个经验很宝贵线上环境排查问题时永远不要先重启从节点。因为重启从节点需要先全量同步一次这在数据量大的时候会放大问题。正确做法是先确认主从状态和数据差距再决定是等待自动恢复还是手动干预。6.3 日常巡检建议我习惯每天固定时间对Redis集群做一次状态巡检。巡检的核心就是看info replication里的几个关键指标主从状态是否online、lag值是否在合理范围、积压缓冲区是否频繁被覆盖。这些指标如果出现异常趋势就算当前还没出故障也要提前处理。此外可以用config get repl-backlog-size确认配置没有被误改用slowlog get查看从节点有没有执行了耗时的命令。这些巡检动作加起来也就几分钟的事但能提前止损很多潜在故障。写在最后我实际维护Redis这几年踩过的最大一个坑就是刚接手一套老环境时发现主节点竟然关闭了持久化从节点配了三个但积压缓冲区全是默认值1MB。结果某次机房网络抖动三台从节点全部掉线恢复后全部触发全量同步主节点IO瞬间被打满线上接口超时报警响了一整片。那次事故之后我才痛定思痛把同步链路的每个参数都按业务写入量重新算了一遍。如果你现在正准备面试或者正要给团队搭建一套Redis高可用环境我建议你按这个顺序去验证先跑通主从复制再用info replication看透所有字段然后人为制造一次断线重连观察增量同步和全量同步触发的边界条件。这套实验做下来你对Redis同步机制的理解绝对不只是停留在背面试题的水平而是真正知道它在生产环境里是怎么工作的。最后再分享一个实用小技巧排查同步问题的时候不要只盯着info replication的lag字段把repl_backlog_histlen和master_repl_offset一起看。前者能告诉你积压缓冲区实际覆盖了多少字节的数据后者能让你精确算出从节点落后了多少数据量。有了这两个数字判断该走增量同步还是全量同步你心里会有底得多。