Redis 主从同步是我这几年用 Redis 过程中觉得最值得讲透的一个机制。很多人会把主从复制当成“备份”其实它更核心的价值是让 Redis 从“单点工具”变成“可水平扩展的基础设施”。单机 Redis 再快也扛不住两类场景一是宕机后所有请求直接打挂二是读流量一上来单节点 CPU 和网卡瞬间成为瓶颈。主从同步就是解决这两个问题的第一步也是后面理解哨兵、集群的基石。这篇文章我会从零开始把主从同步的原理、配置、常见坑一次讲清楚适合刚学完 Redis 基础命令、想进一步理解高可用架构的读者也适合已经在用 Redis 但没系统梳理过复制机制的开发者。1. 为什么需要主从同步单机 Redis 的三个天花板1.1 可用性缺口单点宕机等于业务停摆先聊一个最现实的问题Redis 的所有读写都发生在一个进程里这个进程挂了整个缓存层就没了。有人会说Redis 不是有 RDB 和 AOF 持久化吗重启恢复不就行了但恢复是有代价的如果内存里放着 10G 数据重启后从 RDB 加载可能就要几十秒AOF 重放更是可能分钟级。这几十秒到几分钟里所有缓存请求全部穿透到数据库数据库大概率直接被打垮。主从同步解决的就是这个“空窗期”。你准备一台从节点让它实时同步主节点的数据主节点真出问题了从节点下一秒就能顶上。虽然这时候需要手动切换或配合哨兵但数据已经有一份热备恢复时间从分钟级压缩到秒级。别小看这个差别实际生产环境里数据库能多扛几十秒还是几秒钟直接决定了你这个事故是 P2 还是 P1。1.2 读写分布不均一个主节点扛不住全部读流量第二个场景在电商、内容类的服务里特别常见。一个商品的详情页写操作可能一天就几千次但读操作一个小时就能到几十万次。如果把所有读请求都压在主节点上主节点既要处理写命令又要处理读命令网卡和 CPU 迟早被打满。主从同步天然支持“一主多从”的架构。写操作打到主节点读操作分散到多个从节点每个从节点都有一份完整的数据副本读能力可以近乎线性扩展。我见过一个模拟项目单机 Redis 读 QPS 大概能扛 8 万左右加了三台从节点做读写分离后读 QPS 直接冲到 22 万主节点负载反而降了不少。这就是主从复制最直观的价值。1.3 数据安全单机持久化文件救不了硬件故障RDB 和 AOF 能防“进程崩溃”但防不了“机器损坏”和“磁盘故障”。我实际处理过一次磁盘损坏的事故主节点所在的机器硬盘直接报废RDB 文件跟着一起没了。这时候如果有一个从节点在另一台机器上数据至少还在不至于从零开始重建缓存。另外RDB 持久化本身是耗资源的操作fork 子进程时如果数据量很大主线程会有明显的卡顿。有了从节点之后完全可以在从节点上开启 RDB 持久化把主节点的持久化压力分担掉主节点专心服务读写请求。这是很多团队实际在用的方案效果非常明显。主从同步解决的核心问题就是这三个高可用、读写分离、数据冗余。它是 Redis 从单机走向分布式架构的第一步也是最容易理解的一步。接下来我用实际配置和抓包日志把这个过程完整拆给大家看。2. 从零搭建一主两从配置与验证全流程2.1 实例规划三个 Redis 进程模拟最小集群先不要想得太复杂实际生产环境里主从节点可能是三台不同的物理机但在本地学习或做 Demo 时完全可以用三个不同端口的 Redis 实例模拟。假设我规划的架构是这样节点IP / 端口角色用途节点A127.0.0.1:6379主节点处理写请求节点B127.0.0.1:6380从节点1处理读请求节点C127.0.0.1:6381从节点2处理读请求 / 备份节点这里我用的是同一台机器三个端口主要是为了演示方便。生产环境请务必把主从节点部署在不同的机器上不然一台物理机挂了三个节点一起消失主从复制等于白搭。这是很多人第一次搭主从时容易忽略的点。2.2 两种建立主从关系的方式我先把两种方式都写出来因为实际工作中两种都会遇到。第一种是用配置文件redis.conf 里添加下面这行replicaof 127.0.0.1 6379这是 Redis 5.0 之后推荐的写法。在 5.0 之前这个配置项叫 slaveof虽然现在 Redis 7.x 为了兼容还能识别 slaveof但新项目里建议全部用 replicaof。加了这行配置后从节点启动时会自动向主节点发起同步请求之后每次启动都是自动建立主从关系不需要人为干预。第二种方式是命令动态修改不需要重启进程REPLICAOF 127.0.0.1 6379我比较推荐在临时调整架构时用命令方式比如某个从节点想临时切换复制源一条命令就能搞定不用改配置文件再重启。但要注意命令方式指定的主从关系不会持久化重启之后从节点会回到自己配置文件里的状态没有配置就变回独立节点。如果想保留还是得把 replicaof 写进配置文件。2.3 验证主从是否就绪配置完成后在主节点上执行INFO replication正常情况下主节点会输出类似这样的信息# Replication role:master connected_slaves:2 slave0:ip127.0.0.1,port6380,stateonline,offset1694,lag0 slave1:ip127.0.0.1,port6381,stateonline,offset1694,lag0重点关注几个字段state 必须是 onlineoffset 是两个从节点的复制偏移量lag 是主从之间的延迟秒数。在从节点上执行同样的命令role 应该显示 slave 或者 replica并且能看到 master_link_status:up。快速验证数据是否真的同步过去了可以在主节点写入一个 key然后在从节点直接 GET 一下。能查到就说明链路跑通了。我这里再说一个技巧主节点写入一个随机 key 后如果从节点上查不到不要急着怀疑同步出了问题先确认一下你查的是不是从节点的 6380/6381 端口这类低级错误我见得太多了。3. 主从同步的核心机制全量复制与部分复制3.1 全量重同步第一次建立从属关系的完整流程当从节点第一次连接主节点或者从节点断开太久无法增量恢复时会触发全量重同步。这个过程我拆成四步第一步从节点向主节点发送 PSYNC 命令携带自己的复制 ID 和偏移量。如果从节点是全新节点复制 ID 是 0偏移量是 -1表示“我什么都没有给我全部数据”。第二步主节点收到 PSYNC 后判断需要全量同步于是开始生成 RDB 快照。这个 RDB 生成过程是异步的主节点不会阻塞写请求。但注意如果主节点内存数据量很大fork 生成子进程时可能短暂卡顿所以生产环境要么给主节点预留足够的 CPU 资源要么干脆在从节点上做 RDB。第三步RDB 文件生成完毕后主节点把文件发送给从节点。从节点收到后先把 RDB 加载到内存这个过程中从节点会拒绝所有外部请求所以全量同步期间从节点是“不可用”的。第四步RDB 开始生成之后主节点收到的所有写命令都会被记录在复制积压缓冲区里。RDB 发送完成后主节点会把缓冲区里的命令继续同步给从节点确保从节点最终和主节点在同一个状态。这里有个容易忽略的点全量同步期间从节点的旧数据会被清掉。如果从节点之前已经有一批数据全量同步一触发旧数据直接被 RDB 替换。我遇到过有人想在从节点上保留一些自定义数据结果一同步全没了所以有这种需求就得自己想别的方案主从复制不会帮你保留。3.2 部分重同步断线重连如何避免全量复制全量重同步虽然能解决问题但代价太大尤其是大实例上几 GB 的 RDB 传输会占用大量带宽从节点加载期间还会拒绝服务。最理想的情况是从节点只断开了一小会儿期间主节点产生的写命令不多重连后只补发这部分就行。这就是部分重同步要干的事。部分重同步依赖三个核心要素主节点的 run_id主节点每次启动都会生成一个唯一的运行 ID从节点首次连接时会记住。主从各自的复制偏移量 offset每传输一个字节的命令流offset 就递增一次这个偏移量是判断“落后多少”的依据。复制积压缓冲区主节点维护的一块固定大小的环形内存里面保存着最近一段时间的写命令。当从节点断线重连后会发送 PSYNC 带上自己的 offset。主节点拿到这个 offset如果发现它仍然在自己的复制积压缓冲区范围内就只把缓冲区里 offset 之后的数据发给从节点完成增量补发。如果从节点落后的太多offset 已经不在缓冲区范围内那没办法只能退回全量重同步。复制积压缓冲区的大小直接决定了“能从短时断线中恢复”的容错空间。默认值是 1MB说实话太小了。我建议生产环境按这个公式估算一下缓冲区大小 预估主节点每秒写入字节数 × 可接受的最长断线时间举个例子主节点平均写速率是 2MB/s业务允许从节点断线 60 秒内都能增量恢复那缓冲区至少要设到 120MB。配置项是repl-backlog-size 128mb3.3 复制 ID、偏移量与积压缓冲区怎么协同工作这里我把三个概念放到一起讲清楚因为它们之间的关系比较微妙很多人学了半天还是一团浆糊。复制 ID 是主节点的“身份标识”每次主节点启动都会重新生成。从节点第一次全量同步的时候会把主节点的复制 ID 记成自己的复制 ID后续断线重连时发 PSYNC带上这个 ID 和 offset主节点就能认出“这是我之前那个从节点”。如果主节点重启了复制 ID 会变。这时候从节点带着旧的复制 ID 再来主节点发现自己不认识这个 ID会强制从节点做全量重同步。这就引出一个实际排查经验如果发现从节点频繁做全量复制先看看主节点是不是经常重启或者主节点的复制积压缓冲区是不是挪到了新生成的临时 ID 上。偏移量背后还有一个完整的机制主节点每次向从节点发送写命令时自己也会维护一个 master_repl_offset从节点每接收一条命令自己的 offset 也会更新。所以排查主从是否一致最直接的办法就是从 INFO replication 里对比主节点的 master_repl_offset 和从节点的 slave_repl_offset。两者差值越大说明从节点落后越多。3.4 无盘复制与复制参数调优Redis 2.8.18 引入了无盘复制功能主节点不把 RDB 写入磁盘而是直接在内存中生成 RDB 并同步发送给从节点。这个选项对磁盘性能差的环境非常有用。默认情况下RDB 要先落盘再发送如果磁盘 IO 很慢全量同步的耗时会被拉长。配置项这样设置repl-diskless-sync yes repl-diskless-sync-delay 5其中 repl-diskless-sync-delay 是指主节点生成 RDB 后等多长时间再发给从节点目的是让多个同时请求全量同步的从节点可以共享同一个 RDB 文件避免每个从节点都独立生成一份浪费 CPU。默认 5 秒按需调整。另一个值得关注的参数是 replica-serve-stale-data。默认情况下从节点和主节点断线期间还是会继续响应读请求哪怕读到的可能是过期数据。如果你做的是强一致性场景比如库存查询建议把它关掉replica-serve-stale-data no这样断线期间的从节点会直接拒绝请求宁可不返回数据也不返回错误数据。这个参数很多人在一致性出问题时根本没想到值得记住。4. 实操中遇到的坑主从同步最容易翻车的几个场景4.1 主节点持久化没开从节点一起跟着变“空”这是我在实际运维里遇到最典型的坑。有人为了让主节点性能更好把 save 配置和 appendonly 都关掉了然后搭了主从。平时看起来一切正常主节点写数据从节点同步数据都在。结果某天主节点宕机从节点被提升为新的主节点。最关键的是旧主节点重启后由于没有持久化文件数据是空的而它重启后还会以新主节点的从节点身份出现把满数据的从节点直接覆盖成空数据。这个事故的本质是主从复制只负责“实时同步”不负责“持久化兜底”。如果主节点不开持久化数据从崩溃那一刻起就已经不安全了。我的建议是主节点必须开启 AOF 或至少 RDB从节点可以关持久化或只开 RDB绝不能两边都裸奔。这个坑踩一次就够了代价很大。4.2 从节点偷偷被写入数据主从一直触发全量复制默认情况下从节点是只读的配置文件里 replica-read-only yes 是默认开启的。但有一种情况有人会把它改成 no比如想在从节点上临时做一些本地统计就会往从节点写一些 key。这些 key 在主节点上不存在一旦触发主从重新同步从节点上这些额外的 key 就会被清掉而且如果写入的 key 和主节点上的 key 冲突从节点会一直报错复制链路会反复断连。处理这种问题的标准做法是不要改 replica-read-only从节点上严禁写入。如果有在从节点做计算和统计的需求可以用 Redis 的客户端读数据后在应用层处理或者专门准备一个独立的实例来跑任务别拿从节点当沙盒用。4.3 过期 key 在主从上的行为不一致这是一个隐藏比较深的细节。Redis 删除过期 key 有两种方式惰性删除和主动定期删除。在主从架构中主节点负责生成删除命令然后同步给从节点。从节点不会自己独立去删除过期 key必须等主节点发 DEL 命令过来。这个机制带来的问题是主节点上已经过期但还没被清理的 key从节点上依然能读到。因为从节点判断一个 key 是否过期时如果还没收到主节点的删除指令它是不会主动删的。这在缓存一致性要求高的场景里很容易出问题。我的建议是如果业务对“过期后立即读不到”有强要求最好在应用层加一层过期时间的判断。Redis 从 7.0 开始主从之间对过期 key 处理有了改进但底层“从节点不主动删”的逻辑本质上没有变还是别完全依赖它。4.4 网络抖动引发频繁全量复制从节点和主节点之间的网络如果有轻微抖动物理链路会短暂断开。如果断线时间比较短offset 还在缓冲区范围内重连后能增量恢复。但如果网络一直在“通一下、断一下”的状态每次断线重连时从节点都发起 PSYNC就可能出现一种情况从节点每次恢复一点点又断掉又恢复一点点反而触发不了全量同步但 offset 一直追不上。这种问题最典型的症状是主节点 INFO 里看到从节点状态是 online但是 lag 一直不为 0或者 slave_repl_offset 和 master_repl_offset 的差值在缓慢增加。排查步骤是先看系统日志确认有没有网卡丢包再看内核参数 net.ipv4.tcp_keepalive_time 是否设置得过长。实际处理时我会先把主从节点之间的网络延迟调到 5ms 以内然后把复制积压缓冲区调大给增量恢复留足空间。5. 常见问题排查与速查表5.1 主从复制问题速查表问题现象可能原因排查命令与解决思路从节点 state 为 down网络不通 / 主节点未开启ping 主节点 IP检查防火墙确认主节点在运行从节点一直全量重同步复制积压缓冲区太小 / 从节点落后太多调大 repl-backlog-size检查网络稳定性主从数据不一致主从延迟 / 从节点可写入了数据看 lag 字段关闭从节点写权限检查链路带宽从节点加载 RDB 很慢实例内存大 / 磁盘 IO 慢调大 maxmemory 持久化策略或换 SSD主节点重启后从节点全量同步主节点 run_id 变化尽量让主节点不要频繁重启或用哨兵切换主从之间 offset 无法对齐网络抖动 / 命令阻塞查看 Redis 慢日志分析主节点是否存在阻塞操作这张表是我总结出来的高频问题但实际场景往往更复杂同一个现象可能是多个原因叠加。排查的原则永远是先看状态、再看日志、最后才动配置不要一上来就改参数。5.2 一次同步中断后的全量复制排查实录我分享一个真实的排查过程场景是一个模拟电商项目里的 Redis 主从。某天从节点的 INFO 里显示 master_link_status:down同步完全停掉。我的排查顺序是这样的第一步先看系统日志发现从节点和主节点之间有大量 TCP 重传说明物理链路确实有问题。当时网络工程师反馈是交换机端口抖动属于基础设施故障。第二步网络恢复后从节点自动重连但触发了全量重同步而不是增量恢复。我看了下主节点的配置repl-backlog-size 还是默认的 1MB。主节点在断线期间积累了超过 1MB 的写命令offset 已经超出缓冲区所以只能全量同步。这是我之前提过的参数没调到位造成的。第三步我重新评估了主节点的写速率加了监控后发现高峰期每秒写入约 3MB按 5 分钟断线时间容忍度把 repl-backlog-size 改成了 1GB。改完之后后来一次同样时长的网络抖动从节点重连后恢复增量同步全程只用了不到 1 秒。这个案例的教训是缓冲区的设置一定要结合业务写速率来评估不能用了默认值就以为万事大吉。复制积压缓冲区本质上是“时间换空间”调大了能容忍更长时间的断线但内存占用也会上升需要业务上做取舍。6. 主从复制之外生产环境一定要了解的延伸点6.1 读写分离的隐藏成本很多人做完主从就急着把所有读请求都分发到从节点但没意识到一个问题主从之间的同步是异步的主节点写了一条数据从节点可能落后零点几毫秒。如果业务场景是“写入之后立即读取”比如用户下单后立刻查订单详情请求可能被路由到还没同步完成的从节点上结果查不到。这种问题的解决方案有很多第一种是写入后强制读主节点也就是“写后读一致性”套路第二种是设置一个极短的延迟容忍窗口比如 Redis 主从延迟监控表里 lag 超过 50ms 的从节点就把流量摘掉第三种是给数据加版本号应用层判断过期时间。没有完美方案只有适合业务的方案。6.2 从节点数量不是越多越好一主多从能扛读流量但主节点向所有从节点同步数据也是要开销的。每增加一个从节点主节点就要额外维护一份复制流fork 生成 RDB 时压力也更大。当从节点数量超过 5 个时我建议采用“主 → 从 → 从”的链式复制结构也就是让一部分从节点去同步另一部分从节点减轻主节点的复制压力。链式复制的配置很简单就是让中间层从节点既做从又配置为下一级节点的“主”。但要注意链式复制会增大末端从节点的延迟如果对读新鲜度要求很高层级不要超过两层。6.3 哨兵是主从复制的自动化升级手动做主从切换不是长久之计。主节点宕机时从节点虽然数据在但不会自己转正必须有人去执行 REPLICAOF NO ONE 命令。哨兵就是干这个的它持续监控主节点的健康状态一旦发现主节点失联在多数派哨兵同意的情况下选取一个从节点提升为新主节点并把其他从节点的复制源自动切换到新主上。所以我的建议是生产环境里主从复制必须配合哨兵使用绝不能裸奔。主从复制是“数据冗余”的底座哨兵是“自动切换”的开关两者结合才是高可用的完整体。实测跑了这么久我发现主从复制这个知识点光看文档是学不透的一定要自己搭一次环境、断一次网、刷一批数据亲眼看一下从节点状态怎么变化offset 怎么增长全量同步和增量同步分别在什么时机触发。踩过这些坑之后再去看哨兵和集群你会觉得整个 Redis 高可用体系的逻辑一下就通透了。
Redis 主从同步是我这几年用 Redis 过程中觉得最值得讲透的一个机制。很多人会把主从复制当成“备份”其实它更核心的价值是让 Redis 从“单点工具”变成“可水平扩展的基础设施”。单机 Redis 再快也扛不住两类场景一是宕机后所有请求直接打挂二是读流量一上来单节点 CPU 和网卡瞬间成为瓶颈。主从同步就是解决这两个问题的第一步也是后面理解哨兵、集群的基石。这篇文章我会从零开始把主从同步的原理、配置、常见坑一次讲清楚适合刚学完 Redis 基础命令、想进一步理解高可用架构的读者也适合已经在用 Redis 但没系统梳理过复制机制的开发者。1. 为什么需要主从同步单机 Redis 的三个天花板1.1 可用性缺口单点宕机等于业务停摆先聊一个最现实的问题Redis 的所有读写都发生在一个进程里这个进程挂了整个缓存层就没了。有人会说Redis 不是有 RDB 和 AOF 持久化吗重启恢复不就行了但恢复是有代价的如果内存里放着 10G 数据重启后从 RDB 加载可能就要几十秒AOF 重放更是可能分钟级。这几十秒到几分钟里所有缓存请求全部穿透到数据库数据库大概率直接被打垮。主从同步解决的就是这个“空窗期”。你准备一台从节点让它实时同步主节点的数据主节点真出问题了从节点下一秒就能顶上。虽然这时候需要手动切换或配合哨兵但数据已经有一份热备恢复时间从分钟级压缩到秒级。别小看这个差别实际生产环境里数据库能多扛几十秒还是几秒钟直接决定了你这个事故是 P2 还是 P1。1.2 读写分布不均一个主节点扛不住全部读流量第二个场景在电商、内容类的服务里特别常见。一个商品的详情页写操作可能一天就几千次但读操作一个小时就能到几十万次。如果把所有读请求都压在主节点上主节点既要处理写命令又要处理读命令网卡和 CPU 迟早被打满。主从同步天然支持“一主多从”的架构。写操作打到主节点读操作分散到多个从节点每个从节点都有一份完整的数据副本读能力可以近乎线性扩展。我见过一个模拟项目单机 Redis 读 QPS 大概能扛 8 万左右加了三台从节点做读写分离后读 QPS 直接冲到 22 万主节点负载反而降了不少。这就是主从复制最直观的价值。1.3 数据安全单机持久化文件救不了硬件故障RDB 和 AOF 能防“进程崩溃”但防不了“机器损坏”和“磁盘故障”。我实际处理过一次磁盘损坏的事故主节点所在的机器硬盘直接报废RDB 文件跟着一起没了。这时候如果有一个从节点在另一台机器上数据至少还在不至于从零开始重建缓存。另外RDB 持久化本身是耗资源的操作fork 子进程时如果数据量很大主线程会有明显的卡顿。有了从节点之后完全可以在从节点上开启 RDB 持久化把主节点的持久化压力分担掉主节点专心服务读写请求。这是很多团队实际在用的方案效果非常明显。主从同步解决的核心问题就是这三个高可用、读写分离、数据冗余。它是 Redis 从单机走向分布式架构的第一步也是最容易理解的一步。接下来我用实际配置和抓包日志把这个过程完整拆给大家看。2. 从零搭建一主两从配置与验证全流程2.1 实例规划三个 Redis 进程模拟最小集群先不要想得太复杂实际生产环境里主从节点可能是三台不同的物理机但在本地学习或做 Demo 时完全可以用三个不同端口的 Redis 实例模拟。假设我规划的架构是这样节点IP / 端口角色用途节点A127.0.0.1:6379主节点处理写请求节点B127.0.0.1:6380从节点1处理读请求节点C127.0.0.1:6381从节点2处理读请求 / 备份节点这里我用的是同一台机器三个端口主要是为了演示方便。生产环境请务必把主从节点部署在不同的机器上不然一台物理机挂了三个节点一起消失主从复制等于白搭。这是很多人第一次搭主从时容易忽略的点。2.2 两种建立主从关系的方式我先把两种方式都写出来因为实际工作中两种都会遇到。第一种是用配置文件redis.conf 里添加下面这行replicaof 127.0.0.1 6379这是 Redis 5.0 之后推荐的写法。在 5.0 之前这个配置项叫 slaveof虽然现在 Redis 7.x 为了兼容还能识别 slaveof但新项目里建议全部用 replicaof。加了这行配置后从节点启动时会自动向主节点发起同步请求之后每次启动都是自动建立主从关系不需要人为干预。第二种方式是命令动态修改不需要重启进程REPLICAOF 127.0.0.1 6379我比较推荐在临时调整架构时用命令方式比如某个从节点想临时切换复制源一条命令就能搞定不用改配置文件再重启。但要注意命令方式指定的主从关系不会持久化重启之后从节点会回到自己配置文件里的状态没有配置就变回独立节点。如果想保留还是得把 replicaof 写进配置文件。2.3 验证主从是否就绪配置完成后在主节点上执行INFO replication正常情况下主节点会输出类似这样的信息# Replication role:master connected_slaves:2 slave0:ip127.0.0.1,port6380,stateonline,offset1694,lag0 slave1:ip127.0.0.1,port6381,stateonline,offset1694,lag0重点关注几个字段state 必须是 onlineoffset 是两个从节点的复制偏移量lag 是主从之间的延迟秒数。在从节点上执行同样的命令role 应该显示 slave 或者 replica并且能看到 master_link_status:up。快速验证数据是否真的同步过去了可以在主节点写入一个 key然后在从节点直接 GET 一下。能查到就说明链路跑通了。我这里再说一个技巧主节点写入一个随机 key 后如果从节点上查不到不要急着怀疑同步出了问题先确认一下你查的是不是从节点的 6380/6381 端口这类低级错误我见得太多了。3. 主从同步的核心机制全量复制与部分复制3.1 全量重同步第一次建立从属关系的完整流程当从节点第一次连接主节点或者从节点断开太久无法增量恢复时会触发全量重同步。这个过程我拆成四步第一步从节点向主节点发送 PSYNC 命令携带自己的复制 ID 和偏移量。如果从节点是全新节点复制 ID 是 0偏移量是 -1表示“我什么都没有给我全部数据”。第二步主节点收到 PSYNC 后判断需要全量同步于是开始生成 RDB 快照。这个 RDB 生成过程是异步的主节点不会阻塞写请求。但注意如果主节点内存数据量很大fork 生成子进程时可能短暂卡顿所以生产环境要么给主节点预留足够的 CPU 资源要么干脆在从节点上做 RDB。第三步RDB 文件生成完毕后主节点把文件发送给从节点。从节点收到后先把 RDB 加载到内存这个过程中从节点会拒绝所有外部请求所以全量同步期间从节点是“不可用”的。第四步RDB 开始生成之后主节点收到的所有写命令都会被记录在复制积压缓冲区里。RDB 发送完成后主节点会把缓冲区里的命令继续同步给从节点确保从节点最终和主节点在同一个状态。这里有个容易忽略的点全量同步期间从节点的旧数据会被清掉。如果从节点之前已经有一批数据全量同步一触发旧数据直接被 RDB 替换。我遇到过有人想在从节点上保留一些自定义数据结果一同步全没了所以有这种需求就得自己想别的方案主从复制不会帮你保留。3.2 部分重同步断线重连如何避免全量复制全量重同步虽然能解决问题但代价太大尤其是大实例上几 GB 的 RDB 传输会占用大量带宽从节点加载期间还会拒绝服务。最理想的情况是从节点只断开了一小会儿期间主节点产生的写命令不多重连后只补发这部分就行。这就是部分重同步要干的事。部分重同步依赖三个核心要素主节点的 run_id主节点每次启动都会生成一个唯一的运行 ID从节点首次连接时会记住。主从各自的复制偏移量 offset每传输一个字节的命令流offset 就递增一次这个偏移量是判断“落后多少”的依据。复制积压缓冲区主节点维护的一块固定大小的环形内存里面保存着最近一段时间的写命令。当从节点断线重连后会发送 PSYNC 带上自己的 offset。主节点拿到这个 offset如果发现它仍然在自己的复制积压缓冲区范围内就只把缓冲区里 offset 之后的数据发给从节点完成增量补发。如果从节点落后的太多offset 已经不在缓冲区范围内那没办法只能退回全量重同步。复制积压缓冲区的大小直接决定了“能从短时断线中恢复”的容错空间。默认值是 1MB说实话太小了。我建议生产环境按这个公式估算一下缓冲区大小 预估主节点每秒写入字节数 × 可接受的最长断线时间举个例子主节点平均写速率是 2MB/s业务允许从节点断线 60 秒内都能增量恢复那缓冲区至少要设到 120MB。配置项是repl-backlog-size 128mb3.3 复制 ID、偏移量与积压缓冲区怎么协同工作这里我把三个概念放到一起讲清楚因为它们之间的关系比较微妙很多人学了半天还是一团浆糊。复制 ID 是主节点的“身份标识”每次主节点启动都会重新生成。从节点第一次全量同步的时候会把主节点的复制 ID 记成自己的复制 ID后续断线重连时发 PSYNC带上这个 ID 和 offset主节点就能认出“这是我之前那个从节点”。如果主节点重启了复制 ID 会变。这时候从节点带着旧的复制 ID 再来主节点发现自己不认识这个 ID会强制从节点做全量重同步。这就引出一个实际排查经验如果发现从节点频繁做全量复制先看看主节点是不是经常重启或者主节点的复制积压缓冲区是不是挪到了新生成的临时 ID 上。偏移量背后还有一个完整的机制主节点每次向从节点发送写命令时自己也会维护一个 master_repl_offset从节点每接收一条命令自己的 offset 也会更新。所以排查主从是否一致最直接的办法就是从 INFO replication 里对比主节点的 master_repl_offset 和从节点的 slave_repl_offset。两者差值越大说明从节点落后越多。3.4 无盘复制与复制参数调优Redis 2.8.18 引入了无盘复制功能主节点不把 RDB 写入磁盘而是直接在内存中生成 RDB 并同步发送给从节点。这个选项对磁盘性能差的环境非常有用。默认情况下RDB 要先落盘再发送如果磁盘 IO 很慢全量同步的耗时会被拉长。配置项这样设置repl-diskless-sync yes repl-diskless-sync-delay 5其中 repl-diskless-sync-delay 是指主节点生成 RDB 后等多长时间再发给从节点目的是让多个同时请求全量同步的从节点可以共享同一个 RDB 文件避免每个从节点都独立生成一份浪费 CPU。默认 5 秒按需调整。另一个值得关注的参数是 replica-serve-stale-data。默认情况下从节点和主节点断线期间还是会继续响应读请求哪怕读到的可能是过期数据。如果你做的是强一致性场景比如库存查询建议把它关掉replica-serve-stale-data no这样断线期间的从节点会直接拒绝请求宁可不返回数据也不返回错误数据。这个参数很多人在一致性出问题时根本没想到值得记住。4. 实操中遇到的坑主从同步最容易翻车的几个场景4.1 主节点持久化没开从节点一起跟着变“空”这是我在实际运维里遇到最典型的坑。有人为了让主节点性能更好把 save 配置和 appendonly 都关掉了然后搭了主从。平时看起来一切正常主节点写数据从节点同步数据都在。结果某天主节点宕机从节点被提升为新的主节点。最关键的是旧主节点重启后由于没有持久化文件数据是空的而它重启后还会以新主节点的从节点身份出现把满数据的从节点直接覆盖成空数据。这个事故的本质是主从复制只负责“实时同步”不负责“持久化兜底”。如果主节点不开持久化数据从崩溃那一刻起就已经不安全了。我的建议是主节点必须开启 AOF 或至少 RDB从节点可以关持久化或只开 RDB绝不能两边都裸奔。这个坑踩一次就够了代价很大。4.2 从节点偷偷被写入数据主从一直触发全量复制默认情况下从节点是只读的配置文件里 replica-read-only yes 是默认开启的。但有一种情况有人会把它改成 no比如想在从节点上临时做一些本地统计就会往从节点写一些 key。这些 key 在主节点上不存在一旦触发主从重新同步从节点上这些额外的 key 就会被清掉而且如果写入的 key 和主节点上的 key 冲突从节点会一直报错复制链路会反复断连。处理这种问题的标准做法是不要改 replica-read-only从节点上严禁写入。如果有在从节点做计算和统计的需求可以用 Redis 的客户端读数据后在应用层处理或者专门准备一个独立的实例来跑任务别拿从节点当沙盒用。4.3 过期 key 在主从上的行为不一致这是一个隐藏比较深的细节。Redis 删除过期 key 有两种方式惰性删除和主动定期删除。在主从架构中主节点负责生成删除命令然后同步给从节点。从节点不会自己独立去删除过期 key必须等主节点发 DEL 命令过来。这个机制带来的问题是主节点上已经过期但还没被清理的 key从节点上依然能读到。因为从节点判断一个 key 是否过期时如果还没收到主节点的删除指令它是不会主动删的。这在缓存一致性要求高的场景里很容易出问题。我的建议是如果业务对“过期后立即读不到”有强要求最好在应用层加一层过期时间的判断。Redis 从 7.0 开始主从之间对过期 key 处理有了改进但底层“从节点不主动删”的逻辑本质上没有变还是别完全依赖它。4.4 网络抖动引发频繁全量复制从节点和主节点之间的网络如果有轻微抖动物理链路会短暂断开。如果断线时间比较短offset 还在缓冲区范围内重连后能增量恢复。但如果网络一直在“通一下、断一下”的状态每次断线重连时从节点都发起 PSYNC就可能出现一种情况从节点每次恢复一点点又断掉又恢复一点点反而触发不了全量同步但 offset 一直追不上。这种问题最典型的症状是主节点 INFO 里看到从节点状态是 online但是 lag 一直不为 0或者 slave_repl_offset 和 master_repl_offset 的差值在缓慢增加。排查步骤是先看系统日志确认有没有网卡丢包再看内核参数 net.ipv4.tcp_keepalive_time 是否设置得过长。实际处理时我会先把主从节点之间的网络延迟调到 5ms 以内然后把复制积压缓冲区调大给增量恢复留足空间。5. 常见问题排查与速查表5.1 主从复制问题速查表问题现象可能原因排查命令与解决思路从节点 state 为 down网络不通 / 主节点未开启ping 主节点 IP检查防火墙确认主节点在运行从节点一直全量重同步复制积压缓冲区太小 / 从节点落后太多调大 repl-backlog-size检查网络稳定性主从数据不一致主从延迟 / 从节点可写入了数据看 lag 字段关闭从节点写权限检查链路带宽从节点加载 RDB 很慢实例内存大 / 磁盘 IO 慢调大 maxmemory 持久化策略或换 SSD主节点重启后从节点全量同步主节点 run_id 变化尽量让主节点不要频繁重启或用哨兵切换主从之间 offset 无法对齐网络抖动 / 命令阻塞查看 Redis 慢日志分析主节点是否存在阻塞操作这张表是我总结出来的高频问题但实际场景往往更复杂同一个现象可能是多个原因叠加。排查的原则永远是先看状态、再看日志、最后才动配置不要一上来就改参数。5.2 一次同步中断后的全量复制排查实录我分享一个真实的排查过程场景是一个模拟电商项目里的 Redis 主从。某天从节点的 INFO 里显示 master_link_status:down同步完全停掉。我的排查顺序是这样的第一步先看系统日志发现从节点和主节点之间有大量 TCP 重传说明物理链路确实有问题。当时网络工程师反馈是交换机端口抖动属于基础设施故障。第二步网络恢复后从节点自动重连但触发了全量重同步而不是增量恢复。我看了下主节点的配置repl-backlog-size 还是默认的 1MB。主节点在断线期间积累了超过 1MB 的写命令offset 已经超出缓冲区所以只能全量同步。这是我之前提过的参数没调到位造成的。第三步我重新评估了主节点的写速率加了监控后发现高峰期每秒写入约 3MB按 5 分钟断线时间容忍度把 repl-backlog-size 改成了 1GB。改完之后后来一次同样时长的网络抖动从节点重连后恢复增量同步全程只用了不到 1 秒。这个案例的教训是缓冲区的设置一定要结合业务写速率来评估不能用了默认值就以为万事大吉。复制积压缓冲区本质上是“时间换空间”调大了能容忍更长时间的断线但内存占用也会上升需要业务上做取舍。6. 主从复制之外生产环境一定要了解的延伸点6.1 读写分离的隐藏成本很多人做完主从就急着把所有读请求都分发到从节点但没意识到一个问题主从之间的同步是异步的主节点写了一条数据从节点可能落后零点几毫秒。如果业务场景是“写入之后立即读取”比如用户下单后立刻查订单详情请求可能被路由到还没同步完成的从节点上结果查不到。这种问题的解决方案有很多第一种是写入后强制读主节点也就是“写后读一致性”套路第二种是设置一个极短的延迟容忍窗口比如 Redis 主从延迟监控表里 lag 超过 50ms 的从节点就把流量摘掉第三种是给数据加版本号应用层判断过期时间。没有完美方案只有适合业务的方案。6.2 从节点数量不是越多越好一主多从能扛读流量但主节点向所有从节点同步数据也是要开销的。每增加一个从节点主节点就要额外维护一份复制流fork 生成 RDB 时压力也更大。当从节点数量超过 5 个时我建议采用“主 → 从 → 从”的链式复制结构也就是让一部分从节点去同步另一部分从节点减轻主节点的复制压力。链式复制的配置很简单就是让中间层从节点既做从又配置为下一级节点的“主”。但要注意链式复制会增大末端从节点的延迟如果对读新鲜度要求很高层级不要超过两层。6.3 哨兵是主从复制的自动化升级手动做主从切换不是长久之计。主节点宕机时从节点虽然数据在但不会自己转正必须有人去执行 REPLICAOF NO ONE 命令。哨兵就是干这个的它持续监控主节点的健康状态一旦发现主节点失联在多数派哨兵同意的情况下选取一个从节点提升为新主节点并把其他从节点的复制源自动切换到新主上。所以我的建议是生产环境里主从复制必须配合哨兵使用绝不能裸奔。主从复制是“数据冗余”的底座哨兵是“自动切换”的开关两者结合才是高可用的完整体。实测跑了这么久我发现主从复制这个知识点光看文档是学不透的一定要自己搭一次环境、断一次网、刷一批数据亲眼看一下从节点状态怎么变化offset 怎么增长全量同步和增量同步分别在什么时机触发。踩过这些坑之后再去看哨兵和集群你会觉得整个 Redis 高可用体系的逻辑一下就通透了。
