1. 项目概述为什么主从复制是Redis高可用的基石如果你在生产环境用过Redis大概率会和我一样经历过半夜被报警电话叫醒的“刺激”。单点Redis一旦宕机整个依赖它的应用服务就会瞬间瘫痪数据丢失的风险更是让人头皮发麻。这时候Redis主从复制Replication就成了我们构建稳定服务的第一个也是最重要的防线。它不仅仅是数据的简单拷贝更是实现读写分离、数据备份和故障恢复的核心机制。简单来说主从复制就是让一个Redis服务器主节点Master的数据自动同步到一个或多个Redis服务器从节点Slave上。主节点负责处理写操作从节点则主要承担读请求这样既分摊了主节点的压力也提供了数据冗余。当主节点挂掉时我们可以手动或通过哨兵/集群自动将一个从节点提升为新的主节点从而实现快速故障转移保障服务不中断。理解它的工作流程绝不仅仅是知道“主写从读”这么简单。从最初的连接握手到全量同步时可能遇到的“内存风暴”再到长连接维持与增量同步的细节每一个环节都藏着影响稳定性的关键点。接下来我就结合自己踩过的坑和调优经验把这套流程掰开揉碎了讲清楚。2. 核心流程拆解一次完整同步的五个阶段很多人对主从复制的理解停留在“配置slaveof命令就完事了”的层面这在实际运维中是远远不够的。一次完整的主从建立背后经历了五个严谨的阶段。理解这些阶段是你排查同步问题、进行性能调优的基础。2.1 第一阶段连接建立与身份验证当你在从节点的配置文件里加上replicaof 192.168.1.100 6379Redis 5.0以后推荐使用replicaof与slaveof等价或者运行时执行该命令后从节点并不会立刻开始拉取数据。首先从节点会创建一个到主节点的Socket连接。这个连接是后续所有通信的管道。连接建立后从节点会向主节点发送一个PING命令。这个PING有两个目的一是检查连接是否通畅二是检查主节点是否能够正常处理命令。如果主节点返回了PONG那么第一阶段通过。注意这里第一个坑就来了。如果网络不稳定或者主节点的maxclients连接数已满这个PING/PONG就会失败。我曾遇到过一个案例从节点一直报“Master did not respond to PING, replication aborted”最后发现是主节点的防火墙规则只开了应用端的端口忘了开放给从服务器所在的网段。接下来是身份验证。如果主节点配置了requirepass密码从节点就需要在配置文件中使用masterauth配置相同的密码。连接建立后从节点会发送AUTH命令进行认证。密码错误或未配置主节点会返回一个错误复制流程就此终止。2.2 第二阶段信息同步与端口监听认证通过后主从之间就开始交换关键信息了。从节点会向主节点发送REPLCONF listening-port port命令告知主节点自己正在监听的端口号通常是6379。同时从节点还会发送REPLCONF ip-address ip来告知自己的IP地址。主节点收到这些信息后会将其记录在案。这些信息至关重要尤其是在后续的故障转移和哨兵Sentinel系统中新的主节点需要知道其他从节点的地址以便重新建立复制关系。此时从节点还会发送REPLCONF capa eof capa psync2命令宣告自己支持PSYNC2复制协议以及EOF流式传输等能力这是Redis 4.0之后优化全量复制的关键。2.3 第三阶段数据同步决策——全量还是增量这是整个流程的“决策中枢”。从节点会向主节点发送PSYNC命令尝试进行部分重同步。PSYNC命令的格式是PSYNC replicationid offset。Replication ID可以理解为主节点数据集的唯一“纪元标识”。每当主节点重启或者提升一个从节点为主节点时都会生成一个新的Replication ID。Offset复制偏移量代表从节点当前已复制的数据字节位置。主节点收到PSYNC后会根据传来的参数做出判断全量同步Full Resynchronization如果从节点是第一次连接传的replicationid是?或者从节点传的replicationid与主节点当前的不匹配或者从节点请求的offset偏移量在主节点的复制积压缓冲区Replication Backlog中已经找不到了主节点就会决定进行全量同步。它会回复FULLRESYNC replicationid offset。部分同步/增量同步Partial Resynchronization如果主节点发现从节点传的replicationid与自己当前的一致并且请求的offset之后的数据仍然存在于自己的复制积压缓冲区中那么主节点就会回复CONTINUE然后仅发送从offset之后的数据给从节点。这是最理想、最高效的情况。为什么会有复制积压缓冲区这是一个在主节点内存中维护的固定大小的环形队列默认1MB通过repl-backlog-size配置。主节点处理完每个写命令后不仅会将命令发送给已连接的从节点还会把这个命令写入积压缓冲区。这样短时间断连重连的从节点就可以从这里获取断连期间丢失的数据而不必触发代价高昂的全量同步。2.4 第四阶段数据同步执行——风暴与策略根据上一步的决策数据同步会走向两个截然不同的分支。全量同步流程详解主节点决定全量同步后会立即在后台启动一个bgsave子进程将当前内存中的数据快照RDB文件持久化到磁盘。这是对主节点性能影响最大的一个操作。bgsave会fork一个子进程在数据集很大时比如几十GBfork操作本身可能会造成主进程短暂阻塞与系统内存和内核版本有关。RDB文件生成后主节点会将其发送给从节点。从节点会先清空自己的旧数据如果是第一次同步则是空库然后加载这个RDB文件到内存。这里隐藏着第二个大坑从节点的“内存风暴”。在加载RDB期间从节点的内存使用量会瞬间翻倍旧数据新RDB数据直到加载完成才释放旧数据。如果从节点内存配置和主节点一样且使用率已经较高这个操作很可能直接导致从节点OOMOut Of Memory崩溃。实操心得对于大数据量的实例务必确保从节点的最大内存配置maxmemory至少是主节点的1.5倍以上以应对全量同步时的峰值内存。同时尽量选择在业务低峰期进行主从搭建或重启从节点。增量同步流程详解如果主节点回复了CONTINUE那么流程就轻松多了。主节点会直接从复制积压缓冲区中找到从节点offset之后的所有命令通过连接发送给从节点。从节点就像“补课”一样按顺序执行这些命令最终追上主节点的状态。这个过程对主从节点的资源消耗都极小。2.5 第五阶段命令传播与心跳维持当数据同步无论是全量还是增量完成后主从节点就进入了一个长期的命令传播阶段。此后主节点每执行一个会改变数据集的写命令如SET、LPUSH、DEL等都会异步地发送给所有从节点。从节点接收到命令后会在本地执行一遍从而保证数据的最终一致性。为了维持连接和检测健康状态主从之间会有定期的心跳从节点向主节点默认每秒发送一次REPLCONF ACK offset。这个ACK有两个作用一是向主节点汇报自己当前的复制偏移量二是作为心跳检测。主节点可以根据这个信息判断从节点的网络状态和延迟。主节点向从节点主节点也会定时可通过repl-ping-replica-period配置默认10秒向从节点发送PING检查从节点是否存活。如果心跳超时repl-timeout默认60秒主节点会认为从节点下线并断开复制连接。从节点重连后又会触发新一轮的PSYNC流程。3. 关键参数配置与性能调优实战理解了流程我们就能有的放矢地进行配置和调优。下面这个表格整理了影响主从复制稳定性和性能的核心参数参数默认值作用调优建议repl-backlog-size1mb复制积压缓冲区大小。影响增量同步的能力。强烈建议调大例如设置为256mb或更高。缓冲区越大从节点允许断连的时间窗口就越长越可能触发增量同步而非全量同步。repl-backlog-ttl3600秒主节点在所有从节点断开后积压缓冲区保留的时间。保持默认即可。如果从节点会长时间下线可以适当调大。repl-timeout60秒复制连接超时时间。在跨机房等高延迟网络环境下如果全量同步RDB传输时间很长可能需要适当调大避免传输中途被误判超时断开。client-output-buffer-limit replica256mb 64mb 60主节点为每个从节点设置的输出缓冲区限制。格式hard-limit soft-limit soft-seconds。关键参数。当从节点加载RDB或处理命令较慢时主节点堆积的命令会占用这个缓冲区。如果从节点同步太慢导致缓冲区持续超过限制主节点会断开其连接。对于大数据量或网络慢的场景需要调大例如1024mb 512mb 300。repl-diskless-syncno是否使用无盘复制。开启后主节点生成RDB时不落盘直接通过网络发送给从节点。在磁盘IO性能很差的机器上可以考虑开启yes但要求网络带宽非常好。通常建议关闭磁盘缓冲更稳定。repl-diskless-sync-delay5秒无盘复制时等待更多从节点连接后再开始传输的延迟秒数。配合无盘复制使用目的是让多个从节点共享一次RDB传输。根据从节点数量调整。min-replicas-to-write0主节点至少需要N个从节点连接才接受写请求。用于保证数据可靠性的强一致性场景。例如设置为1意味着至少有一个从节点确认收到数据主节点才会认为写操作成功还需配合wait命令。设置后会增加写延迟影响性能。min-replicas-max-lag10与上一个参数配合定义从节点延迟多少秒以内才算“健康连接”。同上用于一致性保证。调优案例我们有一个业务主节点内存占用约20GB网络带宽是千兆。从节点经常在全量同步时失败。分析发现client-output-buffer-limit replica是默认的256MB。20GB的RDB文件即使在千兆网络下传输也需要约160秒。在这160秒内主节点产生的新写命令会堆积在输出缓冲区很容易就超过256MB导致主节点主动断开从节点连接同步失败。我们将这个限制提升到2048mb 1024mb 300后问题得到解决。同时我们把repl-backlog-size从1MB调整为256MB使得从节点短暂网络抖动后几乎总能通过增量同步恢复避免了频繁的全量同步。4. 常见问题排查与修复实录主从复制在生产中出问题是常态。下面是我总结的几个典型问题场景和排查思路你可以像查字典一样使用。4.1 从节点状态始终为LOADING或同步迟迟不完成现象在从节点执行INFO replication看到master_link_status:up但master_sync_in_progress:1持续很长时间或者从节点对外提供的服务状态是LOADING。排查思路检查主节点日志查看主节点Redis日志确认RDB文件是否已生成并开始传输。如果日志中有“Background saving started”但没有“Background saving terminated”说明bgsave可能卡住了。可能是内存太大fork慢也可能是磁盘空间不足或IO瓶颈。检查网络带宽在从节点上使用iftop、nethogs等工具观察来自主节点IP的网络流量。如果流量远低于网络带宽上限可能是网络问题或主节点性能瓶颈。检查从节点负载登录从节点使用top命令查看Redis进程的CPU占用。在加载RDB文件时Redis进程的CPU使用率会接近100%。如果CPU不高可能进程卡在了其他地方。检查从节点内存这是最常见的原因。使用redis-cli info memory查看used_memory和used_memory_peak。如果内存接近maxmemory限制从节点可能在努力进行内存置换或已经OOM。务必确保从节点maxmemory值足够大。修复方法如果是内存不足扩大从节点内存或清理不必要数据。如果是网络问题检查防火墙、带宽限制。如果是主节点bgsave慢可以考虑在低峰期操作或者为主节点使用更高性能的SSD磁盘。4.2 主从数据不一致现象在主节点写入数据在从节点读取不到或者读到的是旧值。排查思路检查复制偏移量在主节点和从节点分别执行INFO replication。对比master_repl_offset主节点和slave_repl_offset从节点的值。如果从节点的offset长期远小于主节点说明复制有延迟或中断。检查从节点状态确认master_link_status是否为up。如果为down说明复制连接已断开。检查主节点输出缓冲区在主节点执行CLIENT LIST找到从节点对应的连接类型为slave查看obl(output buffer length) 和oll(output list length) 字段。如果值持续很高说明命令在向从节点传播时堆积了从节点处理不过来。检查从节点是否执行了写操作Redis从节点默认是只读的。但通过配置replica-read-only no可以开启写操作。如果从节点被意外写入数据就会造成数据永久不一致。务必确保从节点配置为replica-read-only yes。修复方法对于延迟可以优化从节点性能或网络。对于连接断开让从节点重新执行REPLICAOF命令。对于已经不一致的数据最可靠的方法是在业务低峰期在从节点上执行REPLICAOF NO ONE断开复制然后清空从节点数据FLUSHALL最后重新配置REPLICAOF进行全量同步。这是一个重量级操作需谨慎。4.3 频繁触发全量同步现象从节点重启或网络闪断后总是进行全量同步而不是增量同步。排查思路检查复制积压缓冲区大小repl-backlog-size默认只有1MB。如果主节点写QPS很高1MB的缓冲区可能几秒钟就被新命令覆盖了。从节点断连几分钟后重连请求的offset早已不在缓冲区中。检查从节点重启后的PSYNC参数从节点重启后会丢失之前的replicationid和offset。除非它成功将元信息持久化到了RDB或AOF文件中Redis 4.0的PSYNC2支持部分持久化恢复。检查从节点的RDB/AOF是否正常开启。检查主节点是否重启过主节点重启会生成新的replicationid所有从节点重连都必须进行全量同步。修复方法首要任务是调大repl-backlog-size例如设置为256mb。确保主从节点的Redis版本在4.0以上以支持PSYNC2。为主节点配置持久化这样即使重启只要RDB/AOF文件在就能保持原来的replicationid不完全保证但概率大增。5. 高可用架构中的进阶考量单纯的主从复制解决了数据备份和读扩展但没有解决主节点自动故障转移的问题。这就需要引入Redis Sentinel哨兵或Redis Cluster集群。哨兵模式在主从复制的基础上部署一组独立的哨兵进程来监控主从节点。当主节点被哨兵判定为客观下线时哨兵会自动在从节点中选举出一个新的主节点并通知其他从节点和客户端。主从复制是哨兵实现自动故障转移的数据基础。集群模式实现了数据分片Sharding每个分片由一个主节点和多个从节点组成利用主从复制保证分片内数据冗余。故障转移在分片内部进行。在哨兵或集群环境下主从复制的配置和前述完全一样但需要额外注意网络与部署哨兵节点需要部署在独立的机器或容器上避免与Redis进程同机部署时机器宕机导致监控失效。哨兵之间、哨兵与Redis节点之间的网络需要保持通畅。参数一致性所有主从节点的关键参数如repl-backlog-size、client-output-buffer-limit等建议保持配置一致避免因配置差异导致同步异常。故障转移时的数据丢失窗口即使有哨兵在主节点故障瞬间到从节点被提升为新主节点之前这个时间窗口内主节点未同步到从节点的数据会永久丢失。对于金融等强一致性场景可能需要更复杂的方案或者接受这种异步复制带来的极小概率数据丢失风险。主从复制是Redis所有高可用和分布式特性的根基。把它吃透意味着你不仅能搭建一个可用的主从架构更能从容应对生产环境中各种棘手的同步问题、性能瓶颈和故障场景。每一次故障排查都是对这套流程理解的一次深化。我的经验是把INFO replication命令的输出信息刻在脑子里遇到问题首先看它结合日志大部分复制问题都能找到线索。
1. 项目概述为什么主从复制是Redis高可用的基石如果你在生产环境用过Redis大概率会和我一样经历过半夜被报警电话叫醒的“刺激”。单点Redis一旦宕机整个依赖它的应用服务就会瞬间瘫痪数据丢失的风险更是让人头皮发麻。这时候Redis主从复制Replication就成了我们构建稳定服务的第一个也是最重要的防线。它不仅仅是数据的简单拷贝更是实现读写分离、数据备份和故障恢复的核心机制。简单来说主从复制就是让一个Redis服务器主节点Master的数据自动同步到一个或多个Redis服务器从节点Slave上。主节点负责处理写操作从节点则主要承担读请求这样既分摊了主节点的压力也提供了数据冗余。当主节点挂掉时我们可以手动或通过哨兵/集群自动将一个从节点提升为新的主节点从而实现快速故障转移保障服务不中断。理解它的工作流程绝不仅仅是知道“主写从读”这么简单。从最初的连接握手到全量同步时可能遇到的“内存风暴”再到长连接维持与增量同步的细节每一个环节都藏着影响稳定性的关键点。接下来我就结合自己踩过的坑和调优经验把这套流程掰开揉碎了讲清楚。2. 核心流程拆解一次完整同步的五个阶段很多人对主从复制的理解停留在“配置slaveof命令就完事了”的层面这在实际运维中是远远不够的。一次完整的主从建立背后经历了五个严谨的阶段。理解这些阶段是你排查同步问题、进行性能调优的基础。2.1 第一阶段连接建立与身份验证当你在从节点的配置文件里加上replicaof 192.168.1.100 6379Redis 5.0以后推荐使用replicaof与slaveof等价或者运行时执行该命令后从节点并不会立刻开始拉取数据。首先从节点会创建一个到主节点的Socket连接。这个连接是后续所有通信的管道。连接建立后从节点会向主节点发送一个PING命令。这个PING有两个目的一是检查连接是否通畅二是检查主节点是否能够正常处理命令。如果主节点返回了PONG那么第一阶段通过。注意这里第一个坑就来了。如果网络不稳定或者主节点的maxclients连接数已满这个PING/PONG就会失败。我曾遇到过一个案例从节点一直报“Master did not respond to PING, replication aborted”最后发现是主节点的防火墙规则只开了应用端的端口忘了开放给从服务器所在的网段。接下来是身份验证。如果主节点配置了requirepass密码从节点就需要在配置文件中使用masterauth配置相同的密码。连接建立后从节点会发送AUTH命令进行认证。密码错误或未配置主节点会返回一个错误复制流程就此终止。2.2 第二阶段信息同步与端口监听认证通过后主从之间就开始交换关键信息了。从节点会向主节点发送REPLCONF listening-port port命令告知主节点自己正在监听的端口号通常是6379。同时从节点还会发送REPLCONF ip-address ip来告知自己的IP地址。主节点收到这些信息后会将其记录在案。这些信息至关重要尤其是在后续的故障转移和哨兵Sentinel系统中新的主节点需要知道其他从节点的地址以便重新建立复制关系。此时从节点还会发送REPLCONF capa eof capa psync2命令宣告自己支持PSYNC2复制协议以及EOF流式传输等能力这是Redis 4.0之后优化全量复制的关键。2.3 第三阶段数据同步决策——全量还是增量这是整个流程的“决策中枢”。从节点会向主节点发送PSYNC命令尝试进行部分重同步。PSYNC命令的格式是PSYNC replicationid offset。Replication ID可以理解为主节点数据集的唯一“纪元标识”。每当主节点重启或者提升一个从节点为主节点时都会生成一个新的Replication ID。Offset复制偏移量代表从节点当前已复制的数据字节位置。主节点收到PSYNC后会根据传来的参数做出判断全量同步Full Resynchronization如果从节点是第一次连接传的replicationid是?或者从节点传的replicationid与主节点当前的不匹配或者从节点请求的offset偏移量在主节点的复制积压缓冲区Replication Backlog中已经找不到了主节点就会决定进行全量同步。它会回复FULLRESYNC replicationid offset。部分同步/增量同步Partial Resynchronization如果主节点发现从节点传的replicationid与自己当前的一致并且请求的offset之后的数据仍然存在于自己的复制积压缓冲区中那么主节点就会回复CONTINUE然后仅发送从offset之后的数据给从节点。这是最理想、最高效的情况。为什么会有复制积压缓冲区这是一个在主节点内存中维护的固定大小的环形队列默认1MB通过repl-backlog-size配置。主节点处理完每个写命令后不仅会将命令发送给已连接的从节点还会把这个命令写入积压缓冲区。这样短时间断连重连的从节点就可以从这里获取断连期间丢失的数据而不必触发代价高昂的全量同步。2.4 第四阶段数据同步执行——风暴与策略根据上一步的决策数据同步会走向两个截然不同的分支。全量同步流程详解主节点决定全量同步后会立即在后台启动一个bgsave子进程将当前内存中的数据快照RDB文件持久化到磁盘。这是对主节点性能影响最大的一个操作。bgsave会fork一个子进程在数据集很大时比如几十GBfork操作本身可能会造成主进程短暂阻塞与系统内存和内核版本有关。RDB文件生成后主节点会将其发送给从节点。从节点会先清空自己的旧数据如果是第一次同步则是空库然后加载这个RDB文件到内存。这里隐藏着第二个大坑从节点的“内存风暴”。在加载RDB期间从节点的内存使用量会瞬间翻倍旧数据新RDB数据直到加载完成才释放旧数据。如果从节点内存配置和主节点一样且使用率已经较高这个操作很可能直接导致从节点OOMOut Of Memory崩溃。实操心得对于大数据量的实例务必确保从节点的最大内存配置maxmemory至少是主节点的1.5倍以上以应对全量同步时的峰值内存。同时尽量选择在业务低峰期进行主从搭建或重启从节点。增量同步流程详解如果主节点回复了CONTINUE那么流程就轻松多了。主节点会直接从复制积压缓冲区中找到从节点offset之后的所有命令通过连接发送给从节点。从节点就像“补课”一样按顺序执行这些命令最终追上主节点的状态。这个过程对主从节点的资源消耗都极小。2.5 第五阶段命令传播与心跳维持当数据同步无论是全量还是增量完成后主从节点就进入了一个长期的命令传播阶段。此后主节点每执行一个会改变数据集的写命令如SET、LPUSH、DEL等都会异步地发送给所有从节点。从节点接收到命令后会在本地执行一遍从而保证数据的最终一致性。为了维持连接和检测健康状态主从之间会有定期的心跳从节点向主节点默认每秒发送一次REPLCONF ACK offset。这个ACK有两个作用一是向主节点汇报自己当前的复制偏移量二是作为心跳检测。主节点可以根据这个信息判断从节点的网络状态和延迟。主节点向从节点主节点也会定时可通过repl-ping-replica-period配置默认10秒向从节点发送PING检查从节点是否存活。如果心跳超时repl-timeout默认60秒主节点会认为从节点下线并断开复制连接。从节点重连后又会触发新一轮的PSYNC流程。3. 关键参数配置与性能调优实战理解了流程我们就能有的放矢地进行配置和调优。下面这个表格整理了影响主从复制稳定性和性能的核心参数参数默认值作用调优建议repl-backlog-size1mb复制积压缓冲区大小。影响增量同步的能力。强烈建议调大例如设置为256mb或更高。缓冲区越大从节点允许断连的时间窗口就越长越可能触发增量同步而非全量同步。repl-backlog-ttl3600秒主节点在所有从节点断开后积压缓冲区保留的时间。保持默认即可。如果从节点会长时间下线可以适当调大。repl-timeout60秒复制连接超时时间。在跨机房等高延迟网络环境下如果全量同步RDB传输时间很长可能需要适当调大避免传输中途被误判超时断开。client-output-buffer-limit replica256mb 64mb 60主节点为每个从节点设置的输出缓冲区限制。格式hard-limit soft-limit soft-seconds。关键参数。当从节点加载RDB或处理命令较慢时主节点堆积的命令会占用这个缓冲区。如果从节点同步太慢导致缓冲区持续超过限制主节点会断开其连接。对于大数据量或网络慢的场景需要调大例如1024mb 512mb 300。repl-diskless-syncno是否使用无盘复制。开启后主节点生成RDB时不落盘直接通过网络发送给从节点。在磁盘IO性能很差的机器上可以考虑开启yes但要求网络带宽非常好。通常建议关闭磁盘缓冲更稳定。repl-diskless-sync-delay5秒无盘复制时等待更多从节点连接后再开始传输的延迟秒数。配合无盘复制使用目的是让多个从节点共享一次RDB传输。根据从节点数量调整。min-replicas-to-write0主节点至少需要N个从节点连接才接受写请求。用于保证数据可靠性的强一致性场景。例如设置为1意味着至少有一个从节点确认收到数据主节点才会认为写操作成功还需配合wait命令。设置后会增加写延迟影响性能。min-replicas-max-lag10与上一个参数配合定义从节点延迟多少秒以内才算“健康连接”。同上用于一致性保证。调优案例我们有一个业务主节点内存占用约20GB网络带宽是千兆。从节点经常在全量同步时失败。分析发现client-output-buffer-limit replica是默认的256MB。20GB的RDB文件即使在千兆网络下传输也需要约160秒。在这160秒内主节点产生的新写命令会堆积在输出缓冲区很容易就超过256MB导致主节点主动断开从节点连接同步失败。我们将这个限制提升到2048mb 1024mb 300后问题得到解决。同时我们把repl-backlog-size从1MB调整为256MB使得从节点短暂网络抖动后几乎总能通过增量同步恢复避免了频繁的全量同步。4. 常见问题排查与修复实录主从复制在生产中出问题是常态。下面是我总结的几个典型问题场景和排查思路你可以像查字典一样使用。4.1 从节点状态始终为LOADING或同步迟迟不完成现象在从节点执行INFO replication看到master_link_status:up但master_sync_in_progress:1持续很长时间或者从节点对外提供的服务状态是LOADING。排查思路检查主节点日志查看主节点Redis日志确认RDB文件是否已生成并开始传输。如果日志中有“Background saving started”但没有“Background saving terminated”说明bgsave可能卡住了。可能是内存太大fork慢也可能是磁盘空间不足或IO瓶颈。检查网络带宽在从节点上使用iftop、nethogs等工具观察来自主节点IP的网络流量。如果流量远低于网络带宽上限可能是网络问题或主节点性能瓶颈。检查从节点负载登录从节点使用top命令查看Redis进程的CPU占用。在加载RDB文件时Redis进程的CPU使用率会接近100%。如果CPU不高可能进程卡在了其他地方。检查从节点内存这是最常见的原因。使用redis-cli info memory查看used_memory和used_memory_peak。如果内存接近maxmemory限制从节点可能在努力进行内存置换或已经OOM。务必确保从节点maxmemory值足够大。修复方法如果是内存不足扩大从节点内存或清理不必要数据。如果是网络问题检查防火墙、带宽限制。如果是主节点bgsave慢可以考虑在低峰期操作或者为主节点使用更高性能的SSD磁盘。4.2 主从数据不一致现象在主节点写入数据在从节点读取不到或者读到的是旧值。排查思路检查复制偏移量在主节点和从节点分别执行INFO replication。对比master_repl_offset主节点和slave_repl_offset从节点的值。如果从节点的offset长期远小于主节点说明复制有延迟或中断。检查从节点状态确认master_link_status是否为up。如果为down说明复制连接已断开。检查主节点输出缓冲区在主节点执行CLIENT LIST找到从节点对应的连接类型为slave查看obl(output buffer length) 和oll(output list length) 字段。如果值持续很高说明命令在向从节点传播时堆积了从节点处理不过来。检查从节点是否执行了写操作Redis从节点默认是只读的。但通过配置replica-read-only no可以开启写操作。如果从节点被意外写入数据就会造成数据永久不一致。务必确保从节点配置为replica-read-only yes。修复方法对于延迟可以优化从节点性能或网络。对于连接断开让从节点重新执行REPLICAOF命令。对于已经不一致的数据最可靠的方法是在业务低峰期在从节点上执行REPLICAOF NO ONE断开复制然后清空从节点数据FLUSHALL最后重新配置REPLICAOF进行全量同步。这是一个重量级操作需谨慎。4.3 频繁触发全量同步现象从节点重启或网络闪断后总是进行全量同步而不是增量同步。排查思路检查复制积压缓冲区大小repl-backlog-size默认只有1MB。如果主节点写QPS很高1MB的缓冲区可能几秒钟就被新命令覆盖了。从节点断连几分钟后重连请求的offset早已不在缓冲区中。检查从节点重启后的PSYNC参数从节点重启后会丢失之前的replicationid和offset。除非它成功将元信息持久化到了RDB或AOF文件中Redis 4.0的PSYNC2支持部分持久化恢复。检查从节点的RDB/AOF是否正常开启。检查主节点是否重启过主节点重启会生成新的replicationid所有从节点重连都必须进行全量同步。修复方法首要任务是调大repl-backlog-size例如设置为256mb。确保主从节点的Redis版本在4.0以上以支持PSYNC2。为主节点配置持久化这样即使重启只要RDB/AOF文件在就能保持原来的replicationid不完全保证但概率大增。5. 高可用架构中的进阶考量单纯的主从复制解决了数据备份和读扩展但没有解决主节点自动故障转移的问题。这就需要引入Redis Sentinel哨兵或Redis Cluster集群。哨兵模式在主从复制的基础上部署一组独立的哨兵进程来监控主从节点。当主节点被哨兵判定为客观下线时哨兵会自动在从节点中选举出一个新的主节点并通知其他从节点和客户端。主从复制是哨兵实现自动故障转移的数据基础。集群模式实现了数据分片Sharding每个分片由一个主节点和多个从节点组成利用主从复制保证分片内数据冗余。故障转移在分片内部进行。在哨兵或集群环境下主从复制的配置和前述完全一样但需要额外注意网络与部署哨兵节点需要部署在独立的机器或容器上避免与Redis进程同机部署时机器宕机导致监控失效。哨兵之间、哨兵与Redis节点之间的网络需要保持通畅。参数一致性所有主从节点的关键参数如repl-backlog-size、client-output-buffer-limit等建议保持配置一致避免因配置差异导致同步异常。故障转移时的数据丢失窗口即使有哨兵在主节点故障瞬间到从节点被提升为新主节点之前这个时间窗口内主节点未同步到从节点的数据会永久丢失。对于金融等强一致性场景可能需要更复杂的方案或者接受这种异步复制带来的极小概率数据丢失风险。主从复制是Redis所有高可用和分布式特性的根基。把它吃透意味着你不仅能搭建一个可用的主从架构更能从容应对生产环境中各种棘手的同步问题、性能瓶颈和故障场景。每一次故障排查都是对这套流程理解的一次深化。我的经验是把INFO replication命令的输出信息刻在脑子里遇到问题首先看它结合日志大部分复制问题都能找到线索。
)
