企业官网建设流程全解析

只要在线上跑过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文件发给从节点”，但实际操作远不止传文件这一步。完整流程是这样的：

1. 主节点收到PSYNC后，判定需要全量同步，返回FULLRESYNC <replid> <offset>，告诉从节点“当前主节点的replid是什么，全量快照对应的偏移量是多少”。

2. 主节点执行BGSAVE，fork出一个子进程，把当前内存数据全量写入RDB文件。这里有个细节：BGSAVE期间，主节点自己还在正常服务写请求，这些新的写命令不会进RDB文件。

3. RDB文件生成期间，主节点会把产生的所有新写命令同时写入两个地方：复制积压缓冲区repl_backlog和针对这个从节点的输出缓冲区（replication buffer）。

4. RDB文件生成完毕后，主节点把文件发送给从节点。文件在网络上的传输方式取决于配置——默认是磁盘方式，主节点先把RDB写到磁盘，再从磁盘读出来发；如果开启了repl-diskless-sync yes，主节点直接把RDB数据从内存通过socket发送给从节点，不落盘。

5. 从节点收到完整的RDB文件后，先清空自己的全部旧数据，然后加载RDB内容，重建内存数据。

6. 主节点在RDB发送完毕后，会把复制缓冲区内积压的新命令继续推送给从节点。

7. 从节点按顺序重放这些命令，直到自己的复制偏移量和主节点一致，全量同步结束，后续进入持续的增量推送模式。

这中间最容易出问题的，是第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格式；如果主节点已经升级成hashtable，RDB里就是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重写。从节点如果在同步数据的同时执行BGREWRITEAOF，fork子进程会占用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在传什么、从节点在还原什么；理解了同步机制，你才知道配置参数每一项调节的都是什么。这两块知识拼在一起，才是线上遇到问题时能快速定位方向的底气。