网站源码带采集常熟网站建设书生商友
想象一下大型出版社的印刷车间：主印刷机（Master）以惊人速度印制新书，而多台副印刷机（Replicas）同步复制相同的书籍。
当主印刷机完成一本新书，副印刷机立即获得模板并开始复制。
即使主印刷机需要维护，副印刷机也能继续工作保证书籍供应不断。这种高效协作机制，正是Redis主从复制的完美比喻。
在实际开发中，我们经常遇到这样的场景：
数据库需要处理高并发读取，或者需要灾备机制防止数据丢失。很多人知道Redis支持主从复制，但不一定了解其底层实现细节。根据我的经验，深入理解主从复制机制对于构建高性能、高可用的Redis系统至关重要。
今天，我们就来深入探讨Redis主从复制的底层实现。通过本文，大家将掌握从连接建立到数据同步的全过程，理解Redis如何实现高效可靠的数据复制。
一、复制初始化：建立主从关系
理解了出版社印刷的比喻后，我们来看看Redis如何建立主从关系。在实际工作中，
我们经常会遇到需要配置主从复制的场景，比如读写分离或数据备份。Redis主从复制的初始化过程就像印刷机之间的"握手协议"，确保双方准备好数据同步。
1.1 复制配置方式
Redis提供两种方式配置主从复制：
# 方式1：配置文件设置（永久生效
# 在从节点的redis.conf中添加：
replicaof 192.168.1.100 6379# 方式2：运行时命令（临时生效）
127.0.0.1:6380> REPLICAOF 192.168.1.100 6379\
OK
上述代码展示了配置主从复制的两种方法。replicaof命令（Redis 5.0+）或slaveof命令（旧版本）用于指定主节点。
在生产环境中建议使用配置文件方式，避免重启后配置丢失。但千万要注意主节点的安全配置，避免未授权访问。
1.2 复制初始化流程
当从节点连接到主节点时，会执行以下初始化步骤：
1. 保存主节点信息
从节点执行连接命令，从节点保存主节点的IP和端口到内存中，清除旧的主节点信息。
SLAVEOF <master_ip> <master_port>
- 从节点将主节点信息保存到server.masterhost和server.masterport
- 清除旧复制状态：replicationDiscardCachedMaster()
2. 建立Socket连接
从节点创建与主节点的非阻塞Socket连接，用于后续通信
- 调用connectWithMaster()创建非阻塞Socket
- 底层使用anetTcpNonBlockConnect()（位于anet.c）
3. 发送PING命令
从节点发送PING检查连接是否可用，主节点回复PONG确认
从节点发送: PING
主节点回复: PONG
- 从节点状态变为REPL_STATE_RECEIVE_PONG
- 超时处理：repl_timeout（默认60秒
4. 权限验证
如果主节点设置了requirepass，从节点发送AUTH命令验证
从节点发送: AUTH <password>
主节点回复: +OK
- 密码存储在server.masterauth
- 认证失败会断开连接并重试
5. 发送端口信息
从节点发送REPLCONF listening-port 告知主节点自己的监听端口和相关自身信息
从节点发送: REPLCONF listening-port <port>
主节点回复: +OK从节点发送: REPLCONF ip-address <ip> # 如果配置了slave-announce-ip
主节点回复: +OK从节点发送: REPLCONF capa eof capa psync2 # 声明支持的能力
主节点回复: +OK
二、数据同步：全量与增量复制
掌握了主从关系的建立后，我们面临核心问题：
如何高效同步数据？
这就像印刷车间需要同步最新的书籍模板。Redis的数据同步分为全量复制和增量复制两个阶段，针对不同场景采用最优策略。
关键命令与步骤：
在从节点已经链接上主节点之后会进行PSYNC协商：
从节点发送: PSYNC <replid> <offset>
主节点进行检查，判断是全量还是增量同步:
if (replid匹配 && offset在repl_backlog范围内) {回复: +CONTINUE <new_replid>
} else {回复: +FULLRESYNC <replid> <offset>
}
2.1 全量复制：RDB快照传输
当从节点首次连接或需要完全同步时，触发全量复制：
# 主节点日志示例
1:M 20 Jan 2024 10:30:15.123 * Replica 127.0.0.1:6380 asks for synchronization
1:M 20 Jan 2024 10:30:15.125 * Starting BGSAVE for SYNC with target: disk
1:M 20 Jan 2024 10:30:15.567 * Background saving started by pid 7890
1:M 20 Jan 2024 10:30:20.345 * Synchronization with replica 127.0.0.1:6380 succeeded
上述日志展示了主节点处理全量复制的完整过程：
- 从节点请求同步
- 主节点启动BGSAVE
- 后台保存完成
- 同步成功。
全量复制流程：
- 主节点执行BGSAVE命令生成RDB快照
- 生成期间的新命令写入复制缓冲区（replication buffer）
- 主节点将RDB文件传输给从节点
- 从节点清空旧数据，加载RDB文件
- 主节点发送复制缓冲区中的命令
主节点执行：
fork() -> rdbSave() -> 通过Socket发送RDB文件
相关日志:
* MASTER <-> REPLICA sync: Flushing old data
* MASTER <-> REPLICA sync: Loading DB in memory
⚠️ 千万要避免： 在大数据集上频繁全量复制。10GB以上的全量复制可能导致网络阻塞和服务中断。我建议大家在添加从节点时选择业务低峰期。
2.2 增量复制：复制积压缓冲区
当网络闪断或短暂中断后重连时，Redis使用增量复制避免全量同步：
# 主节点配置文件关键参数
repl-backlog-size 64mb # 复制积压缓冲区大小
repl-backlog-ttl 3600 # 缓冲区保留时间（秒）
增量复制工作原理：
- 主节点维护固定大小的环形缓冲区（repl-backlog-buffer）
- 持续记录写命令和偏移量（replication offset）
- 从节点断线重连后发送自己的偏移量
- 主节点检查偏移量是否在缓冲区内
- 如果在，发送缺失的命令；否则触发全量复制
三、命令传播：持续同步机制
理解了初始同步后，我们来看看Redis如何保持主从数据的持续一致。这就像印刷车间需要实时同步最新修订的书籍内容。命令传播阶段是主从复制中最活跃、最关键的环节。
3.1 命令传播流程
1. 执行命令
主节点执行客户端发送的写命令
SET user:1001 “name:John”
2. 传播命令
主节点将写命令发送给所有从节点
REPL传播：\*3\r\n$3\r\nSET\r\n$10\r\nuser:1001\r\n$10\r\nname:John\r\n
3. 从节点执行
从节点收到命令后执行相同操作
保持数据与主节点一致
3.2 心跳检测机制
Redis通过心跳机制维护主从连接健康：
# 从节点定期发送REPLCONF ACK
127.0.0.1:6380> REPLCONF ACK 12345678 # 发送当前复制偏移量# 主节点关键配置
repl-ping-replica-period 10 # 主节点ping从节点间隔（秒）
repl-timeout 60 # 复制超时时间（秒）
REPLCONF ACK命令让主节点了解从节点的复制进度，同时作为心跳保持连接活跃。
总结：主从复制机制全景图
通过今天的讨论，相信大家对Redis主从复制的底层实现有了全面的理解。让我们总结一下关键点：
- 复制初始化：主从节点建立连接、验证身份、准备同步
- 数据同步：全量复制（RDB快照）和增量复制（积压缓冲区）
- 命令传播：主节点实时传播写命令，心跳机制保持连接
在实际应用中，没有放之四海而皆准的配置。通过我的观察，合理的主从复制配置可以使系统性能提升50%以上。我建议大家在生产环境中：
中小集群
repl-backlog-size 64mb
repl-timeout 60
大型集群
repl-backlog-size 128-256mb
client-output-buffer-limit 1gb 512mb 300
高延迟网络
repl-disable-tcp-nodelay no
增大repl-timeout
希望通过本文的分享，能帮助大家少走弯路，构建更健壮的Redis系统。欢迎在评论区分享你的主从复制实践经验和问题！