1. Redis主从复制机制深度解析
Redis主从复制是构建高可用Redis架构的基石技术。我在生产环境部署过数十套Redis主从集群，这套机制本质上是通过异步复制实现数据冗余，当主节点(Master)写入数据后，会自动将写命令传播给从节点(Slave)。这种设计带来了三个核心价值：
- 数据热备份：从节点实时同步主节点数据，避免单点故障导致数据丢失
- 读写分离：主节点处理写请求，从节点承担读流量，提升整体吞吐量
- 故障恢复：当主节点宕机时，可快速提升从节点为新主节点
关键细节：Redis4.0之前采用全量+增量复制，4.0后引入PSYNC2实现了故障切换时的部分重同步
2. 主从复制核心流程拆解
2.1 复制初始化阶段
当执行SLAVEOF 127.0.0.1 6379命令时，从节点会经历以下握手流程：
- 保存主节点信息：将主节点的IP和端口持久化到redis.conf
- 建立socket连接：从节点创建与主节点的网络连接（端口6379）
- 发送PING命令：检测主节点是否可处理请求
- 权限验证：如果配置了requirepass，发送AUTH命令
- 同步数据：根据主节点状态决定全量或增量同步
# 查看复制状态的命令示例 redis-cli info replication2.2 数据同步机制
全量同步（RDB文件传输）
当从节点首次连接或主从复制ID不匹配时触发：
- 主节点执行bgsave生成RDB快照
- 传输期间的新写命令存入复制缓冲区
- RDB传输完成后加载到从节点内存
- 主节点发送缓冲区积压的写命令
增量同步（命令传播）
正常运行时采用此模式：
- 主节点将写命令发送到复制积压缓冲区
- 异步传播给所有从节点
- 从节点通过偏移量确认同步进度
避坑指南：复制缓冲区大小通过
repl-backlog-size配置，生产环境建议设为128MB-1GB
3. 生产环境配置实战
3.1 主节点关键参数
# redis.conf主节点配置 repl-diskless-sync yes # 无盘复制(适用于SSD环境) repl-backlog-size 1gb # 复制积压缓冲区 min-slaves-to-write 1 # 至少1个从节点在线才接受写3.2 从节点优化配置
replica-read-only yes # 从节点只读 repl-ping-replica-period 10 # 心跳间隔 repl-timeout 60 # 复制超时时间3.3 拓扑结构选择
根据业务需求选择不同架构：
- 星型拓扑：单主多从（适合读多写少）
- 链式复制：主→从→从（降低主节点压力）
- 级联复制：主→从(同时作为其他节点主)
4. 常见问题排查手册
4.1 复制中断问题
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
从节点显示disconnected | 网络中断 | 检查防火墙/网络配置 |
| 主从数据不一致 | 缓冲区溢出 | 增大repl-backlog-size |
| 同步速度慢 | 主节点负载高 | 启用无盘复制或升级硬件 |
4.2 性能优化技巧
- 主节点避免执行
KEYS *等阻塞命令 - 从节点配置
slave-lazy-flush减少重启同步时间 - 使用
repl-diskless-sync加速全量同步 - 监控
master_repl_offset差值预警延迟
5. 主从复制与哨兵联动
当结合Sentinel使用时需注意：
- 主从切换后，Sentinel会自动修改从节点配置
- 建议设置
slave-priority参数控制提升顺序 - 故障转移期间可能出现短暂数据不一致
# 查看哨兵监控状态 redis-cli -p 26379 sentinel masters我在金融级业务中验证过的配置经验是：主节点和从节点最好部署在相同规格的硬件上，避免从节点因性能不足成为瓶颈。曾经遇到过从节点使用低配虚拟机导致复制延迟持续增长的情况，最终通过统一硬件规格解决
