1. 从单点故障到数据冗余为什么需要主从复制如果你负责的线上服务其核心缓存突然宕机导致所有请求瞬间穿透到数据库引发雪崩你会怎么办这绝不是危言耸听而是许多后端工程师都曾经历或恐惧过的场景。Redis作为高性能的内存数据存储虽然速度极快但其数据存储在内存中的特性也意味着一旦服务进程崩溃或服务器宕机所有数据都可能面临丢失的风险。即便开启了RDB或AOF持久化在故障发生时从磁盘恢复数据也需要时间这段时间的服务不可用对于核心业务来说往往是不可接受的。这就是Redis主从复制Replication要解决的核心问题高可用与数据备份。它通过将一台Redis服务器主节点Master的数据实时或最终同步到一台或多台Redis服务器从节点Slave上来实现数据的冗余。这样当主节点发生故障时我们可以快速地将流量切换到某个从节点从而保证服务的连续性。此外主从架构还能分担读压力主节点专注于写操作多个从节点可以共同处理大量的读请求实现读写分离提升系统的整体吞吐量。很多人初次接触主从复制时可能会觉得它和MySQL的主从复制类似都是“一个写多个读”。但在细节上尤其是数据同步的流程和机制Redis有其独特之处。理解这些细节不仅是为了面试时能对答如流更是为了在实际运维中能够从容应对主从延迟、数据不一致、故障切换等复杂问题。接下来我们就深入Redis内部拆解主从复制完整的工作流程。2. 主从复制的核心流程全景图Redis的主从复制过程本质上是一个数据同步的状态机。它并非一蹴而就而是分阶段、分步骤进行的。整个流程可以清晰地划分为三个阶段建立连接阶段、数据同步阶段和命令传播阶段。每个阶段都有其特定的目标和行为任何一个环节出现问题都可能导致复制链路中断或数据不一致。我们可以把主从复制想象成一位老师主节点向一位新学生从节点传授一本厚厚的百科全书全量数据。首先学生需要找到老师并建立联系建立连接。然后老师会把整本书的复印本一次性交给学生数据同步。最后在以后的日子里老师每在原著上新增或修改一页内容就会立刻把这一页的更新笔记发给学生让学生同步更新自己的复印本命令传播。这个比喻大致勾勒出了流程轮廓但真实的Redis实现远比这精细和复杂。例如在“交接复印本”的过程中老师主节点并不会停止撰写新内容处理写命令这些新内容会被暂时记录在一个笔记本复制缓冲区里等交接完复印本后再一并交给学生。如果笔记本记满了或者学生接收太慢就可能出问题。下面我们就来逐一拆解这三个核心阶段。2.1 第一阶段连接建立与身份确认复制流程的启动始于从节点。你需要明确一点在Redis中复制关系是由从节点主动发起的。主节点被动地等待从节点的连接。这通常通过在从节点的配置文件redis.conf中设置replicaof masterip masterport指令或者在从节点启动后执行REPLICAOF masterip masterport命令来实现。当从节点执行了上述配置后它会尝试与指定的主节点建立网络连接。这个连接是一个持久的、专用于复制命令的TCP连接。连接建立成功后从节点会立即向主节点发送一个PING命令。这个PING有两个目的一是检查连接是否畅通二是验证主节点是否能正常处理命令。如果主节点返回了PONG则表示链路基本正常。紧接着从节点会进行身份验证如果主节点配置了requirepass。从节点会使用AUTH命令并附上配置中指定的密码通过masterauth配置项进行认证。如果密码错误主节点会拒绝复制请求连接将被关闭。注意这里有一个常见的坑。如果你在主节点设置了密码但忘记在从节点的配置文件中配置masterauth那么从节点会一直卡在尝试复制的状态并不断报错。日志中通常会看到 “-NOAUTH Authentication required.” 或 “-ERR invalid password” 之类的信息。务必确保主从双方的认证配置匹配。身份验证通过后从节点会向主节点发送REPLCONF listening-port port和REPLCONF ip-address ip命令告知主节点自己的监听端口和IP地址。这些信息会被主节点记录用于管理复制集群和后续的故障感知。至此连接建立阶段完成主从双方做好了数据同步的准备。2.2 第二阶段全量数据同步的“快照”传输连接建立后从节点会向主节点发送PSYNC命令正式请求开始数据同步。PSYNC命令是Redis 2.8之后引入的它支持部分重同步而之前的SYNC命令只支持全量同步。PSYNC命令的格式是PSYNC replicationid offset。Replication ID可以理解为主节点数据集的唯一标识符。每当主节点重启或者晋升为一个新的主节点时都会生成一个新的Replication ID。Offset从节点当前已复制的数据偏移量复制积压缓冲区中的位置。对于第一次建立复制关系的从节点它没有之前的复制上下文所以会发送PSYNC ? -1表示请求一次全量同步。主节点收到PSYNC命令后会根据参数判断如何进行同步如果从节点提供的 Replication ID 与当前主节点的不匹配或者从节点的 offset 偏移量在主节点的复制积压缓冲区中已不存在主节点会判定需要进行全量同步回复FULLRESYNC replicationid offset。否则主节点会尝试进行部分同步回复CONTINUE并仅发送从节点缺失的那部分命令。对于初次连接的从节点必然走全量同步的流程。主节点在回复FULLRESYNC后会立即启动一个后台进程执行bgsave命令将当前内存中的数据生成一个RDB快照文件。这是全量同步过程中对主节点性能影响最大的操作因为bgsave会fork一个子进程在数据集很大时fork操作可能耗时且消耗较多内存。在生成RDB文件的同时主节点并不会阻塞它会继续处理客户端发来的写命令。这些新接收到的写命令主节点会一边处理一边将它们缓存到专门的复制积压缓冲区Replication Backlog中。这是一个固定大小的环形缓冲区默认1MB可以通过repl-backlog-size配置。当RDB文件生成完毕后主节点会通过之前建立的复制连接将这个RDB文件传输给从节点。从节点会清空自己的旧数据如果是非空节点启动复制然后加载这个RDB文件将自己的数据库状态恢复到主节点执行bgsave那一刻的快照。实操心得全量同步的耗时和资源消耗主要取决于主节点数据集的大小。对于一个有几十GB数据的Redis生成和传输RDB文件可能会持续数分钟甚至更久。在此期间网络带宽会被大量占用。因此在规划主从架构时应尽量避免频繁的全量同步例如避免随意重启从节点并确保复制积压缓冲区大小 (repl-backlog-size) 设置合理以覆盖一般网络闪断或从节点短暂重启的时间窗口。2.3 第三阶段增量命令传播与持续同步从节点成功加载完RDB文件后其数据状态就与主节点在开始bgsave那个时间点一致了。但是在主节点生成和传输RDB文件的这段时间里主节点又接收并处理了新的写命令。这些命令都保存在之前提到的复制积压缓冲区里。因此全量同步完成后复制流程并没有结束。主节点会将自己复制积压缓冲区中从RDB文件生成时刻开始到当前时刻为止的所有写命令一并发送给从节点。从节点执行这些命令从而使自己的数据与主节点达到最终一致。从此之后复制就进入了稳定状态的命令传播阶段。主节点每执行一个会改变数据集的写命令如SET、LPUSH、DEL等除了向发起请求的客户端返回结果外还会将这个命令异步地发送给所有从节点。从节点接收到命令后会在本地执行一遍从而保证主从数据的实时同步。这个传播是异步的这意味着主节点不会等待从节点执行完命令后再返回给客户端。这也是主从延迟产生的根本原因。如果从节点因为自身处理速度慢、网络波动等原因未能及时应用主节点传播过来的命令就会导致从节点上的数据落后于主节点。3. 深入PSYNC2部分重同步的救赎在早期的SYNC时代任何原因导致的复制中断如网络抖动、从节点重启在重新连接后都需要进行一次耗时的全量同步这非常低效。PSYNC机制的出现特别是Redis 4.0引入的PSYNC2极大地优化了这个问题其核心就是利用了我们反复提到的复制积压缓冲区Replication Backlog和Replication ID。复制积压缓冲区是一个在内存中维护的、固定长度的先进先出FIFO队列。主节点在命令传播阶段不仅会把命令发给从节点还会把命令以协议格式写入这个缓冲区。缓冲区就像一个滑动窗口记录着最近一段时间内主节点执行的所有写命令。每个命令在缓冲区中都有一个偏移量offset。主节点和从节点都会维护自己当前复制进度的offset。当从节点短暂断开又重连后它会带着自己断连前最后的offset和Replication ID向主节点发送PSYNC replicationid offset。主节点收到请求后会进行以下判断检查从节点传来的Replication ID是否与自己的当前ID或上一个ID存储在master_replid2中匹配。这用于处理主节点故障切换Failover后的场景。如果ID匹配则检查从节点传来的offset是否还存在于自己的复制积压缓冲区中。只要从节点落后的数据量没有超过缓冲区的容量即offset还在缓冲区窗口内主节点就可以只将从节点缺失的那部分命令从offset开始到缓冲区最新位置发送给从节点这就是部分重同步。这个过程非常高效通常能在毫秒级完成数据同步避免了巨大的全量数据传输。为了确保部分重同步的成功率你需要合理设置repl-backlog-size。一个简单的估算方法是缓冲区大小 平均网络中断时间(秒) * 平均写流量(字节/秒)。例如如果你的应用平均每秒产生100KB的写命令为了容忍10秒的网络中断缓冲区至少应设置为1MB。在生产环境中对于写流量较大的场景将其设置为几十MB甚至上百MB是常见的做法。4. 主从延迟监控、成因与优化实践主从延迟是主从复制架构中最常见的问题之一。它指的是从节点上的数据相对于主节点存在滞后。过高的延迟会带来风险在故障切换时如果切换到延迟很高的从节点可能会丢失一部分最新的数据。如何监控延迟Redis提供了直观的命令来监控复制状态。在主节点或从节点上执行INFO replication命令可以获取详细信息。其中master_repl_offset表示主节点当前已写入复制流的全局偏移量。在从节点的信息中slave_repl_offset表示从节点已处理的偏移量。两者的差值(master_repl_offset - slave_repl_offset)就是延迟的字节数。你可以通过监控系统定期采集这个差值来观察延迟情况。延迟产生的主要原因有哪些网络带宽瓶颈或延迟这是最常见的原因。如果主从节点跨机房部署网络本身的延迟和有限的带宽会成为命令传播的瓶颈。主节点每秒产生大量写命令而网络无法及时将这些命令传输到从节点。从节点性能不足如果从节点的服务器配置CPU、内存、磁盘IO低于主节点或者从节点上运行了其他消耗资源的进程可能导致其处理主节点传播过来的命令的速度跟不上主节点产生命令的速度。特别是如果从节点开启了持久化如AOF的everysec模式磁盘IO可能成为瓶颈。主节点写入压力过大如果主节点在短时间内接收到海量写请求产生命令的速度超过了从节点处理能力和网络传输能力的总和缓冲区会迅速被填满即使网络和从节点性能正常也会产生延迟。慢查询阻塞从节点在执行主节点传播过来的命令时如果某个命令执行得很慢例如对一个超大集合执行KEYS *或一个复杂的Lua脚本会阻塞后续命令的执行导致复制线程卡住延迟急剧上升。优化延迟的实战策略网络优化尽可能将主从节点部署在同一个局域网IDC内避免跨公网或跨地域部署。如果必须异地考虑使用专线或云服务商的内网高速通道。监控网络带宽使用率和延迟。硬件资源对等确保从节点的硬件配置尤其是CPU、内存和磁盘性能不低于主节点。避免在从节点上部署其他重型应用。合理配置缓冲区适当调大repl-backlog-size例如256MB或更大给网络波动留出足够的缓冲空间。同时可以调整repl-backlog-ttl缓冲区存活时间防止从节点长时间断开后缓冲区被清空。控制主节点写入流量对于突发的大量写入可以考虑在客户端进行限流或队列缓冲避免瞬间压垮复制链路。分析并优化产生大量写入的业务逻辑。避免从节点执行慢查询确保不会在从节点上直接执行KEYS、FLUSHALL等危险命令。对于复杂的只读操作可以考虑使用redis-cli --intrinsic-latency检测慢查询并进行优化。使用树状复制在从节点数量很多的情况下让所有从节点都连接同一个主节点会给主节点的网络出口带宽带来巨大压力。可以采用树状结构让部分从节点通常称为“二级从节点”或“子从节点”去连接另一个从节点而不是直接连接主节点从而分摊主节点的复制压力。5. 复制风暴与运维中的常见陷阱即使理解了原理在实际运维中仍然会遇到一些棘手的问题。其中一个典型问题就是复制风暴。想象一个场景一个主节点(M0)下有多个从节点(S1, S2, S3)。当主节点M0因故障重启后它的Replication ID发生了变化。此时所有从节点(S1, S2, S3)重连时发现Replication ID不匹配且自己落后的数据可能已超出缓冲区范围于是它们会同时向主节点M0发起全量同步请求。主节点M0不得不几乎同时为多个从节点执行bgsave并传输巨大的RDB文件。这会导致主节点服务器磁盘IO和网络IO被瞬间打满。主节点内存压力剧增多个bgsave的fork操作。整个服务响应变慢甚至不可用。这就是复制风暴。要缓解这个问题可以采取以下措施错峰重启/切换在计划内维护时避免同时重启所有从节点。可以逐个进行。设置合理的repl-backlog-size确保缓冲区足够大使得从节点在短暂中断后能进行部分同步而不是全量同步。使用树状复制减少直接挂载在主节点下的从节点数量。升级到Redis 4.0以上版本PSYNC2机制通过维护master_replid2能在主节点重启后如果数据未丢失一定程度上支持部分同步降低了风暴概率。另一个常见陷阱是关于从节点的可写性。默认情况下Redis从节点是只读的replica-read-only yes。这是为了防止用户误操作直接在从节点写入数据导致主从数据不一致。但有些开发者为了图方便可能会临时关闭这个设置在从节点上做测试性写入。这极其危险因为主节点的同步命令会直接覆盖从节点上的任何本地修改导致数据混乱且难以排查。务必保持从节点的只读属性。最后监控复制链路状态至关重要。不能只监控主节点。需要监控所有从节点的INFO replication输出关注master_link_status应为up、slave_repl_offset是否在增长、以及与主节点master_repl_offset的差值。设置告警当复制链路断开或延迟超过阈值时能及时通知运维人员。理解Redis主从复制的工作流程不仅仅是掌握几个命令和配置项更是构建稳定、可靠缓存架构的基础。从连接建立到数据同步再到持续的增量传播每一个环节都有其设计考量和潜在的故障点。在实际工作中结合监控数据深入理解这些原理才能让你在面临主从延迟、数据不一致、故障切换等问题时能够快速定位根因并采取有效的优化或修复措施确保你的缓存服务坚如磐石。