Redis主从复制的核心价值
Redis主从复制最直接的用处就是数据冗余备份。当主节点挂掉时，从节点可以快速顶上，业务几乎感觉不到中断。很多电商平台在大促期间，就是靠这个机制扛住突发流量。
主从架构还能分担读压力，主库专注写操作，多个从库分担读请求。实测在1主2从的配置下，查询QPS能提升2-3倍。特别是那些读多写少的场景，比如内容缓存、商品详情页，效果特别明显。
搭建主从复制的关键步骤
protected-mode设为nobind 127.0.0.1requirepass密码replicaof 主节点IP 6379repl-timeoutmasterauth 主节点密码
replica-read-only yes
参数 主节点 从节点 protected-mode no no daemonize yes yes replicaof - 必填 性能调优实战技巧
网络延迟优化是个重点。遇到过跨机房复制的案例，默认配置下同步延迟经常超过5秒。后来调整了两个参数：从60调到120repl-ping-replica-period从10调到5 缓冲区配置直接影响同步效率。如果主节点写入量大， 把client-output-buffer-limit的replica项调大，比如改成512mb 128mb 300。曾经有个游戏服务器，高峰期每秒10万+写入，就是靠这个参数避免复制中断。replica常见故障排查指南
主从断开连接时，先看日志里的
状态。常见错误有：masterauth密码不对：检查 是否匹配info replication内存不足：从节点需要和主节点相同的内存配置 版本不兼容：Redis 6.x主节点不能复制到5.x从节点 通过
命令能看到详细的复制状态，重点关注master_link_status和master_last_io_seconds_ago这两个指标。如果master_link_status是down，说明复制链路断了，需要检查网络连接和认证信息。
Redis主从复制对版本兼容性其实挺敏感的，特别是跨大版本混搭时容易踩坑。4.x和6.x虽然都支持主从复制，但底层协议已经做了不少优化调整，比如6.x新增的PSYNC2协议在4.x上压根就不支持。实际运维中就遇到过6.x主节点向4.x从节点复制时，某些特殊命令会导致从节点直接卡死的情况，最后只能重启从节点才能恢复。
搭建主从集群时，所有节点尽量统一使用5.0-6.2版本范围内的稳定版。如果非要混用版本，记住一个铁律：从节点版本绝对不能低于主节点。比如可以用6.x的从节点连接5.x的主节点，反过来就很容易出问题。有些团队为了平滑升级，会先批量升级从节点到新版本，等运行稳定后再升级主节点，这个策略确实能有效降低风险。
常见问题解答
Redis主从复制延迟过高怎么解决？
主从复制延迟通常由网络带宽不足或配置不当引起。 先检查网络状况，适当增大repl-timeout和client-output-buffer-limit参数值。对于跨机房部署，可以考虑使用专线网络，或者调整repl-disable-tcp-nodelay参数为no以减少小包传输延迟。
主节点宕机后如何手动切换从节点？
当主节点故障时，首先在从节点执行REPLICAOF NO ONE命令将其提升为主节点，然后修改其他从节点的replicaof配置指向新主节点。 配合哨兵(Sentinel)实现自动故障转移，可以避免人工操作失误。
主从节点数据不一致如何修复？
发现数据不一致时，可以先在从节点执行REPLICAOF NO ONE断开复制，然后通过redis-cli rdb导出主节点数据快照，最后在从节点重新建立复制关系。对于关键业务， 定期使用INFO replication命令检查master_repl_offset是否同步。
Redis 4.x和6.x版本能否混搭主从复制？
Redis 4.x和6.x版本在复制协议上有差异，不 混搭使用。实测表明，6.x主节点向4.x从节点复制时，可能出现命令不兼容的情况。最佳实践是保持主从节点版本一致，至少保证主节点版本不高于从节点版本。
主从复制会影响Redis性能吗？
复制过程确实会消耗额外资源，主节点需要额外10-20%的CPU和网络带宽来处理复制流量。但通过合理配置repl-backlog-size和repl-diskless-sync参数，可以将影响控制在5%性能损耗以内。读写分离架构带来的查询性能提升通常能抵消这部分开销。
