只要在线上跑过Redis主从架构早晚会撞上一次“主从切换后数据少了一点”或者“从节点同步风暴”的诡异问题。这个问题的根源往往不在网络不在机器负载而在你对Redis主从同步机制和对象模型的理解深度。市面上聊Redis主从的教程很多但大多只讲“怎么配”不讲“同步的时候数据到底怎么流动、内存里的对象到底怎么被复制和重建”。这篇文章我把这两块拼在一起讲透主从同步的完整链路、Redis的对象模型是怎么设计的、以及两者碰撞时最容易出坑的几个地方。1. 先想清楚一件事Redis主从复制到底复制的是什么1.1 从节点不是“备份机”而是“写命令的复读机”很多人对主从复制的理解停留在“主节点定期把数据拷贝一份给从节点”这个理解方向就错了。Redis的复制不是整体拷贝而是基于**操作流command stream**的异步复制。主节点每执行一条写命令除了改自己的内存数据还会把这条命令写进复制缓冲区然后异步推送给所有从节点。从节点拿到命令后按顺序在自己的内存里重放一遍最终和主节点达到一致状态。这一点和MySQL的基于binlog的复制思路很像但Redis更极端——它整个复制的粒度就是一条条命令没有行级数据的概念。所以你问“同步到底复制的什么”答案很直接复制的是导致数据变更的那条命令不是数据本身。这也解释了为什么主从集群里从节点最好不要写数据。如果你在从节点上用SET写了一个主节点不存在的key主节点不会管你它只负责把自己的命令推给从节点而不会把你手工写的key同步给别的节点。从节点上有主节点没有的数据这就是“发散”的开始后面所有一致性排查都会变得很难受。1.2 异步复制带来的三个必然结果既然复制是异步的你就要接受三个客观现实第一个是延迟窗口。主节点执行完命令到从节点执行完相同命令中间有网络传输和本地执行的时间差。这个时间差通常极小但在大事务、大key、网络抖动时会被明显放大。通过INFO replication里的master_repl_offset和slave_repl_offset差值可以实时看到这个窗口有多大。第二个是数据丢失风险。如果主节点在某条命令还没推给从节点的时候宕机从节点晋升为主节点后这条命令对应的数据就永久丢了。Redis官方文档明确说了主从复制是弱一致性的默认配置下最多可能丢失数秒的写数据。生产环境想降低这个风险只能调min-replicas-to-write和min-replicas-max-lag让主节点在从节点延迟过大时直接拒绝写请求但这是个双刃剑会影响可用性。第三个是同步启动时的全量重建成本比较高。从节点第一次接入主节点或者断线时间太久无法增量追平主节点就要把整个数据集导出一份给从节点。这一步的成本和你的数据量成正比数据量越大导出的时间越长对主节点性能的影响也越大。1.3 一个主节点到底能挂多少从节点从理论上看一个主节点可以挂非常多的从节点Redis没有硬性数量限制。但实际生产环境里你会发现从节点一旦超过三四个主节点的压力会明显上升。原因很简单主节点每多一个从节点就要多维护一份复制缓冲区、多建立一条TCP连接、多发送一份数据。如果某个从节点处理能力跟不上主节点还要额外花时间和它的网络拥堵作斗争。所以大型系统里更常见的拓扑是树状结构主节点下面挂两三个一级从节点每个一级从节点再挂自己的子从节点。子从节点从一级从节点同步数据这样主节点只需要把数据推给少量一级节点。代价是链路上的延迟叠加但换来的是主节点压力的有效分摊。这种设计在跨机房场景里尤其常见——一个机房放主节点和一级从节点另一个机房放子从节点流量不用全部集中到主节点出口。2. 主从同步的完整链路从PSYNC到全量重建2.1 握手阶段从节点怎么找到主节点从节点启动时配置文件里的replicaof指令会告诉它主节点的IP和端口。从节点会先和主节点建立TCP连接然后发送PING确认主节点活着再发送REPLCONF listening-port把自己监听的端口告诉主节点这样主节点的INFO replication里能显示每个从节点的地址。接下来从节点发送REPLCONF capa eof capa psync2声明自己支持的特性。之后就是关键的PSYNC命令。从节点会带上两个参数发给主节点replication ID简称replid和offset复制偏移量。第一次连接时从节点不知道主节点的replid是什么就发送?和-1断线重连时从节点会带上前一次同步记住的replid和offset。2.2 主节点的判断逻辑走全量还是走增量主节点收到PSYNC后要做两个判断第一个判断是replid是否匹配。如果从节点传过来的replid和主节点当前的replid一致说明从节点之前就是从我这个主节点同步的历史渊源对得上。如果不一致说明从节点可能曾经从别的节点同步过或者是新来的主节点就认为自己对它来说是个全新的节点直接走全量同步。第二个判断是offset是否还在复制积压缓冲区内。主节点内存里维护着一个环形缓冲区repl_backlog用来保存最近一段时间产生的最新写命令。如果从节点请求的offset落在缓冲区内说明断线期间丢失的命令都还在可以用增量同步追平。如果offset已经滑出缓冲区范围时间太久了或者从节点上报的offset比主节点当前最新offset还靠前数据错乱主节点就只能让它走全量同步。这两个判断有一个不满足就会走全量同步。2.3 全量同步的完整流程全量同步听起来简单——“把RDB文件发给从节点”但实际操作远不止传文件这一步。完整流程是这样的主节点收到PSYNC后判定需要全量同步返回FULLRESYNC replid offset告诉从节点“当前主节点的replid是什么全量快照对应的偏移量是多少”。主节点执行BGSAVEfork出一个子进程把当前内存数据全量写入RDB文件。这里有个细节BGSAVE期间主节点自己还在正常服务写请求这些新的写命令不会进RDB文件。RDB文件生成期间主节点会把产生的所有新写命令同时写入两个地方复制积压缓冲区repl_backlog和针对这个从节点的输出缓冲区replication buffer。RDB文件生成完毕后主节点把文件发送给从节点。文件在网络上的传输方式取决于配置——默认是磁盘方式主节点先把RDB写到磁盘再从磁盘读出来发如果开启了repl-diskless-sync yes主节点直接把RDB数据从内存通过socket发送给从节点不落盘。从节点收到完整的RDB文件后先清空自己的全部旧数据然后加载RDB内容重建内存数据。主节点在RDB发送完毕后会把复制缓冲区内积压的新命令继续推送给从节点。从节点按顺序重放这些命令直到自己的复制偏移量和主节点一致全量同步结束后续进入持续的增量推送模式。这中间最容易出问题的是第2步到第5步之间的时间窗口。RDB文件越大生成和传输的时间越长复制缓冲区内积压的命令就越多。如果积压的命令量超过了client-output-buffer-limit replica的限制主节点会直接断开这个从节点——注意是全量同步失败不是暂停。这也是为什么大实例做全量同步时经常碰到“同步一把就断断了又全量全量又断”的死循环。2.4 repl_backlog到底多大合适复制积压缓冲区repl_backlog是整个增量同步的核心基石它本质上是一个环形缓冲区默认大小只有1MB。这个默认值对生产环境来说几乎肯定是不够的。因为断线重连时只要断线期间主节点产生的写命令总量超过缓冲区容量最老的那部分命令就被覆盖了从节点就追不上了只能全量同步。我给你的建议是用公式算而不是凭感觉配。假设你的业务高峰期每秒钟产生大约5000条写命令每条命令平均100字节断线恢复目标时间是60秒。那么缓冲区至少需要5000 * 100 * 60 30MB。这还只是单次断线的情况如果短时间内反复断线实际需要更充裕的余量。我在生产环境一般配置为repl-backlog-size 256mb起步写密集型的实例直接上512MB。内存成本不高但能避免很多全量同步的麻烦。还有一点值得注意repl_backlog是全局共享的不管你有几个从节点都共用同一个缓冲区。主节点向缓冲区写入数据每个从节点各自记录自己的offset各自去缓冲区里取自己缺的那段。所以真正的好处在于只要缓冲区够大多个从节点同时断线重连都能增量追平不会同时触发多份全量同步。2.5 断线重连和PSYNC2的演进Redis 2.8之前从节点只要一断线重连后必然全量同步代价巨大。2.8引入了PSYNC解决了“断开时间不长时可以增量追平”的问题。但第一版PSYNC有个漏洞如果发生主从切换原从节点晋升为新主节点其他老从节点重连时发现replid变了又只能全量同步。Redis 4.0引入了PSYNC2核心改进是让新主节点继承旧主节点的replid并且维护一个replid历史列表。这样切换后老从节点发现新主的replid和自己记忆中旧主的replid能对应上并且offset也在合理范围内依然可以增量追平避免了切换后的“全量同步风暴”。这也是为什么强调生产环境尽量使用Redis 4.0以上版本——光是这一条就能在故障切换时省下大量时间和带宽。3. 对象模型数据在Redis内存里的真实形态3.1 redisObject所有value的统一外壳聊完同步该聊对象模型了。这两个话题看似独立实际上在RDB加载、命令重放、过期键处理这些环节是深度耦合的。先看对象模型本身。Redis里的每个value不管你是存字符串、列表还是哈希底层都用一个叫redisObject的结构体包装。这个结构体包含几个关键字段type数据类型就是STRING、LIST、HASH、SET、ZSET这些。encoding底层具体编码方式比如字符串可能是int、embstr或raw。ptr指向真实数据存储结构的指针。refcount引用计数用来做内存共享和回收。lru或lfu记录对象被访问的时间或频率信息供内存淘汰用。很多人第一次看到encoding这个字段时会困惑数据类型和编码方式不是一一对应的吗为什么要单独拆出来答案是为了内存效率和CPU效率的平衡。同一个数据类型在数据量小时可以用紧凑的内存布局数据量大了再切换成更复杂的结构。用encoding字段来标记当前用的是哪种布局查询时就能按对应方式解析。3.2 字符串的三种编码int、embstr、raw字符串是所有类型中最基础的也是编码变化最丰富的。当一个字符串能解析为整数且长度不超过20位时Redis会直接用int编码ptr直接存整数本身不分配额外内存。比如SET foo 12345这个value在内存里就是8字节的长整型比存字符串省得多。当字符串长度不超过44字节时使用embstr编码。这种编码的特点是redisObject结构和字符串数据分配在同一块连续内存里一次内存分配搞定对CPU缓存友好。字符串超过44字节后切换为raw编码redisObject和字符串数据分别分配独立内存。这个44字节的阈值常有人问是怎么来的。它和Redis的内存分配器jemalloc的分配粒度有关——一次分配64字节最适合redisObject结构本身占用16字节剩下48字节给字符串内容再减去sdshdr头部的开销最终可用作字符串内容的就是44字节。3.3 哈希、列表、集合、有序集合的编码演进列表在Redis 3.2之前是ziplist和linkedlist二选一3.2引入quicklist后统一改为quicklist。quicklist本质上是一个双向链表每个节点是一个压缩的ziplist片段兼顾了内存紧凑性和两端插入的高效性。Redis 7.0之后内部把ziplist逐步替换为listpack进一步解决了ziplist的级联更新问题。哈希使用listpack旧版本叫ziplist存储小规模数据当字段数超过hash-max-listpack-entries默认128或某个字段值长度超过hash-max-listpack-value默认64字节时升级为hashtable编码。集合的小数据量场景用intset内部存一个有序整数数组查询靠二分查找。当元素数量超过set-max-intset-entries默认512或者插入了一个非整数元素就升级为hashtable。有序集合在小数据量时用listpack超过zset-max-listpack-entries默认128或zset-max-listpack-value默认64后切换为skiplist dict的组合结构。skiplist负责排序和范围查询dict负责O(1)精确查找member对应的score。用OBJECT ENCODING key命令可以随时看到某个key当前的实际编码。生产环境里排查内存问题时这个命令的价值很高——你以为是字符串太多占内存一查很可能发现某个hash因为字段特别大全部升级成了hashtable内存占用翻了几倍。3.4 编码转换是单向的而且有一个容易忽略的点编码升级基本是单向的数据量从小变大编码从紧凑型变成复杂型反过来删除大量数据后编码通常不会自动降回紧凑型。比如一个hash曾经有200个字段升成了hashtable后来删除到只剩10个字段它依然保持hashtable编码。这不算bug是Redis为了避免频繁编码切换做的取舍。但在主从场景里有个容易被忽略的点主从同步时命令重放会完整还原主节点的编码状态。比如主节点一个hash是hashtable编码全量同步时RDB文件里记录的就是hashtable的存储形态从节点加载后也是hashtable。增量同步时主节点执行的HSET命令原样传到从节点从节点执行后如果触发了编码升级从节点的编码状态也会同步升级。也就是说正常情况下主从两边的对象编码完全一致。这就意味着你在从节点上用OBJECT ENCODING观察到的编码能真实反映主节点数据的情况。但反过来说如果你在从节点上手工执行了跟主节点不一致的操作比如直接改从节点的maxmemory-policy配置就可能破坏这种一致性。4. 同步和对象模型碰撞时才会暴露的坑4.1 过期键主从策略不一致会出大问题这是主从架构里最经典的暗坑。Redis的过期键删除策略分两个层面惰性删除每次访问key时检查是否过期和主动删除/定期删除后台循环抽样清理过期key。主节点两种策略都启用每次删除一个过期键时会同步往复制流里写一条DEL命令从节点收到后也会删除。从节点自己只做惰性删除不会主动清理过期的key它依赖主节点的DEL命令来清除。问题就出在这里从节点上的过期key在主节点的DEL命令到达之前如果被查询到会返回什么答案是返回空Redis在处理读请求时会先检查key是否过期过期了就当作不存在处理。所以从业务层面看没问题。但从内存层面看从节点上可能堆积了大量已过期但还没收到DEL命令的key。更隐蔽的问题在主从切换后暴露。假设主节点宕机从节点晋升为新主节点。晋升的那一瞬间它会重新启用主动删除策略开始清理那些“以前等待主节点DEL命令”的过期key。如果过期key非常多清理动作会占用主线程CPU造成新主节点短暂的延迟毛刺。生产环境里主从切换后偶尔出现的“新主节点CPU莫名飙高”很多时候就是这一下清理引起的。4.2 内存淘汰策略两边策略不一致会让同步卡壳maxmemory-policy配置决定了Redis内存写满后怎么淘汰key。主节点每次淘汰key也会同步一条DEL给从节点理论上两边能保持一致。但如果你给从节点配置了不同于主节点的maxmemory或者maxmemory-policy事情就不对了。比如主节点配的是allkeys-lru内存还有富余从节点配了更小的maxmemory写满后它会按照自己的策略淘汰key这些淘汰动作产生不了DEL命令同步给主节点方向反了于是从节点上开始出现主节点没有的“幽灵缺失”主节点能查到数据从节点查不到或者干脆从节点淘汰掉的key在主节点上还活着。我的建议很简单从节点不要配置独立的maxmemory要么不设要么和主节点保持一致。从节点的内存本来就该跟主节点相同规模如果因为预算问题给从节点配了更小的内存那真正该调整的是整个集群的规格而不是让从节点单独承担淘汰压力。4.3 RDB加载时的编码还原不只是一个“读文件”的过程全量同步时从节点加载RDB文件、重建内存数据的过程比你想象的更依赖对象模型。RDB格式不只是一条条“键值对”记录它包含了每个key对应的编码信息。Redis在持久化时会按照对象当前的实际编码方式把数据写入文件加载时同样按照这个编码方式还原。所以如果主节点的某个hash是listpack编码RDB里记录的也是listpack格式如果主节点已经升级成hashtableRDB里就是hashtable的存储格式。从节点加载后得到的对象编码和主节点完全一致。这个机制保证了数据在复制过程中的“形态一致性”但也带来一个性能隐患RDB加载本质上是在做一次完整的对象构建过程不是简单的“读进内存”。加载时遇到大key需要分配大量内存、构造复杂数据结构这些操作都发生在主线程上加载期间从节点对外无法提供正常服务。曾经遇到过线上从节点加载一个8GB的RDB文件耗时将近两分钟期间该从节点的所有读请求全部超时。4.4 replication buffer和repl_backlog不是一回事排查主从同步问题时经常有人混淆这两个缓冲区。repl_backlog是全局的所有从节点共享用来支撑增量同步而replication buffer是每个从节点独立拥有的输出缓冲区用来暂存即将发给这个从节点的数据。主节点向repl_backlog写入数据的同时也会向每个从节点的输出缓冲区写入数据。这两个缓冲区的满员处理方式也不同。repl_backlog满了只会覆盖旧数据不影响从节点连接但replication buffer如果超过了client-output-buffer-limit replica的阈值主节点会直接断开这个从节点。日志里看到类似“MASTER - REPLICA sync: client-output-buffer-limit replica reached”的报错就是这个原因。这种断连在数据量大的实例上出现过不止一次全量同步刚开始RDB还没传完积压的写命令已经撑爆了输出缓冲区主节点断开连接从节点再次重连又一次全量同步形成死循环。遇到这种场景可以临时调大这个阈值比如CONFIG SET client-output-buffer-limit replica 512mb 256mb 60同时排查为什么短时间积累了这么多写命令。4.5 从节点晋升主节点后复制参数不会自动调优主从切换后原从节点变成了新主节点但很多参数是跟着配置文件走的不会自动变化。最常见的问题是新主节点继续沿用旧配置里偏小的repl-backlog-size而它的写入流量可能比旧主节点更大下一次从节点断线重连时增量同步的成功率就会降低。所以在做故障切换演练时我一般会把repl-backlog-size、client-output-buffer-limit replica、repl-diskless-sync这些同步相关参数整理成一组切换后第一时间检查新主节点的配置必要时动态调整避免在一个不合适的时间点触发全量同步。5. 线上实战排查主从同步问题的一条完整链路5.1 场景一主从延迟持续增大读数据总是偏旧一个典型的场景是主从延迟从几毫秒逐渐增加到几百毫秒甚至几秒业务上读取从节点数据时经常拿到旧值。排查的第一步永远是看INFO replication的输出。重点关注两个字段master_repl_offset和slave_repl_offset两个值的差就是当前滞后量。再配合INFO stats里sync_total和sync_full的次数判断是否经常发生全量同步。如果滞后量持续增加而不是回落通常有几个原因主节点有大key写入。比如一次写入一个几十MB的字符串主节点自身执行很快但网络传输和从节点内存分配耗时很长这个时间窗口内新增的其他命令都会堆积在缓冲区里。从节点在做AOF重写。从节点如果在同步数据的同时执行BGREWRITEAOFfork子进程会占用CPU和内存IO导致接收命令的速度下降滞后量就会拉大。从节点服务器性能不足。特别是使用了机械硬盘或者CPU主频偏低的环境同样的命令在主节点上只要几微秒在从节点上可能要几毫秒。验证手段用redis-cli --latency配合SLOWLOG GET比较直接。在从节点上跑慢日志如果看到大量SET、LPUSH等写命令耗时偏高就说明从节点本地处理能力成了瓶颈。大key问题用redis-cli --bigkeys就能扫出来。5.2 场景二网络抖动一次所有从节点全部全量同步这个场景通常是repl_backlog设置不合理造成的。网络断了几秒期间主节点的写命令量超过了缓冲区容量最老的那部分命令被覆盖所有从节点重连后发现自己的offset已经滑出了缓冲区范围只能全部走全量同步。多个从节点同时全量对主节点CPU、磁盘IO、网络带宽都是极大冲击严重时会让主节点本身也抖动起来形成连锁反应。排查时用INFO replication看sync_full计数如果数值在故障前后跳变基本就能确认。预防手段上面已经说完调大repl-backlog-size用公式估算而不是拍脑袋。另外一个容易忽视的点如果主节点开启了AOF持久化全量同步时会先生成RDB再发送RDB生成期间的新写命令也存在AOF缓冲区里。AOF文件的写入策略如果配置为always磁盘的写入压力会明显影响同步性能通常建议主节点使用everysec从节点可以关闭AOF或按需开启。5.3 场景三从节点内存比主节点大很多或小很多如果主从两边数据量一致正常情况内存占用差异应控制在合理范围内。但实际中用INFO memory对比经常发现从节点的used_memory_rss比主节点大出好几GB。常见原因是从节点处理了大量读请求导致内存碎片化更严重。mem_fragmentation_ratio超过1.5时说明实际向操作系统申请的内存远大于数据占用的逻辑内存这在长期高并发读的从节点上非常常见。另一个原因是客户端连接缓冲和查询缓冲同一个从节点如果接了更多连接或某个客户端执行了大型查询这些临时内存都会被算进RSS里。这种差异一般不影响数据一致性但会影响你给从节点设置内存规格时的判断。不要因为从节点内存占用高就轻松扩容先确认是数据差异还是内存碎片差异。判断方法很简单INFO memory里的used_memory逻辑内存如果主从基本一致说明数据没有实质偏移问题在used_memory_rss和碎片率。5.4 场景四全量同步反复失败日志一直报错日志里反复出现“Full resync from master”又反复失败最典型的根因就是第4.4节说到的replication buffer溢出。但还有一种容易被忽略的情况主节点和从节点的TCP参数不匹配比如主节点设置了很小的tcp-keepalive从节点却在长时间加载RDB时没有任何网络交互主节点误判从节点已离线直接断开连接。解决思路是分两层处理。第一层调大超时和缓冲区限制给同步过程足够的宽容度第二层降低同步的触发概率也就是缩小RDB文件体积、降低同步期间的写压力。如果数据集非常大还可以考虑用REPLICAOF命令手动控制同步节奏先让从节点追到差不多再放开读流量。6. 几个值得写进团队规范里的实践建议围绕主从同步和对象模型这几年陆陆续续踩了不少坑有几点已经固定成我自己的团队规范简单分享一下。第一主从节点配置尽量一致。包括maxmemory、maxmemory-policy、repl-backlog-size、appendonly这些参数主从差异越少切换后出问题的概率越低。即使有些参数在不同节点上可以根据角色有不同配置比如从节点不开AOF也要有意识地在切换预案里写明切换后要调整哪些参数。第二定期做主从数据一致性校验。Redis没有内置的完整校验工具但可以用redis-full-check这类外部工具定期对主从两边的数据做比对。我一般选择业务低峰期执行重点校验大key和热key所在的分片。尤其是经历过主从切换、从节点手工写入、过期key清理等操作的实例数据不一致的风险会显著升高。第三注意观察对象编码的变化趋势。INFO keyspace只能看到key数量看不到编码分布。我会写一个简单的巡检脚本抽样调用OBJECT ENCODING如果发现大量key的编码意外升级比如hash从listpack变成hashtable说明数据规模的某个阈值被突破了要么是业务字段数增长要么是某个大字段进入了value这时候就该评估是否需要调整相关配置参数。第四主从切换演练要纳入常规运维。同步机制本身不难理解难的是在故障切换的那一刻所有参数和状态都处于非理想状态。只有实际演练过一次从节点晋升、老从节点重连、增量追平的全过程你才会真正理解replid切换和repl_backlog容量对系统稳定性的影响有多深。Redis的主从复制设计得相当精巧但精巧不等于无脑。理解了对象模型你才知道RDB在传什么、从节点在还原什么理解了同步机制你才知道配置参数每一项调节的都是什么。这两块知识拼在一起才是线上遇到问题时能快速定位方向的底气。