FFFire小火1. Redis主从复制架构全景透视
Redis主从复制作为分布式缓存系统的基石，其设计哲学源于CAP理论中的CP权衡。在分布式环境下，主从架构通过数据冗余实现了故障转移的基础能力。与常见的全量同步+增量同步模式不同，Redis的复制流程在4.0版本后引入了PSYNC2优化，使得断线重连后的同步效率提升显著。
主从关系的建立始于SLAVEOF命令的执行，这个看似简单的命令背后触发了一系列精妙的协议交互。当从节点配置主节点信息后，首先会尝试建立socket连接，此时主节点会为每个从节点单独创建复制缓冲区（repl_backlog），这个环形缓冲区的尺寸通过repl-backlog-size参数配置，默认1MB，但在生产环境需要根据写入量调整。
关键细节：复制缓冲区大小计算公式应为：平均写入速率(MB/s) × 最大断连时间(s) × 安全系数(1.5~2)。例如系统峰值写入2MB/s，要求容忍30秒断连，则至少需要90MB缓冲区。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 复制流程深度拆解
2.1 全量同步的幕后机制
当新从节点加入或主从版本不兼容时，会触发全量同步流程。这个过程远比表面上的RDB传输复杂：
- 主节点执行bgsave生成RDB时，会启用复制积压缓冲区记录期间的所有写命令
- RDB文件传输采用分块方式，通过TCP窗口大小动态调整传输速率
- 从节点接收期间会将新写入命令暂存到复制客户端缓冲区
- 加载RDB前从节点会清空所有数据，此时若有客户端访问会返回LOADING错误
实测发现，当数据集超过10GB时，RDB生成和传输可能耗时数分钟。此时如果主节点写入压力大，复制缓冲区可能溢出，导致不得不重新全量同步。这就是为什么大型集群需要控制单个实例的容量。
2.2 增量同步的优化艺术
PSYNC机制通过复制偏移量（replication offset）和运行ID（run ID）实现断点续传。但有几个隐藏陷阱：
- 主节点重启后run ID变化会导致PSYNC退化为SYNC
- 网络抖动可能导致偏移量跳跃，触发全量同步
- 从节点提升为主节点后需特殊处理run ID继承
在Redis 6.2版本中，新增了repl-diskless-sync配置项，支持无盘复制。当启用时，主节点直接将RDB通过socket发送给从节点，避免了磁盘I