Redis主从复制原理与配置详解

当你的Redis实例内存占用飙升、读写延迟变大，或者担心单点故障导致数据丢失时，主从复制是第一个应该考虑的解决方案。Redis主从复制能让从节点实时同步主节点的数据，提供读扩展和故障转移的基础。本文将从原理到配置，带你一步步搭建一个可用的主从架构。

主从复制到底解决了什么问题

在没有复制的情况下，Redis实例一旦宕机，内存中的数据会全部丢失（除非开启了AOF或RDB持久化，但恢复期间服务不可用）。主从复制提供了一份实时的数据副本：从节点持续接收主节点的写操作并应用到自身，即使主节点宕机，从节点也能立即接管。同时，你可以将读请求分散到从节点，降低主节点压力。

理解复制原理前，先明确两个角色：主节点（master）和从节点（replica）。从节点启动后，会向主节点发送PSYNC命令请求同步。主节点根据情况决定执行全量同步还是增量同步。

当从节点第一次连接，或者主从之间的复制积压缓冲区（repl_backlog）中已没有从节点所需的偏移量时，主节点会执行全量同步：

全量同步的代价较高，尤其在数据量大的时候会消耗大量网络和磁盘I/O。因此，生产环境应尽量避免频繁的全量同步。

如果从节点与主节点断开后重新连接，且断线期间主节点的写命令仍然在复制积压缓冲区中，主节点会执行增量同步：只发送从节点缺失的写命令，避免全量同步的开销。增量同步依赖主节点的repl-backlog-size配置，默认1MB。如果缓冲区太小，从节点长时间断开就会导致全量同步。

假设你已有两个Redis实例，分别运行在192.168.1.10（主）和192.168.1.11（从），端口均为6379。下面演示如何将从节点配置为跟随主节点。

在从节点的配置文件（redis.conf）中添加一行：

replicaof 192.168.1.10 6379

然后重启从节点服务。如果主节点设置了密码，还需要添加：

masterauth yourpassword

在从节点上通过redis-cli执行：

REPLICAOF 192.168.1.10 6379

这种方式即时生效，但重启后会失效，除非同时写入配置文件。

在从节点执行INFO replication，关注以下字段：

role:slave
master_host:192.168.1.10
master_port:6379
master_link_status:up
slave_repl_offset:12345

如果master_link_status为up，说明连接正常。在主节点执行INFO replication，可以看到从节点列表：

connected_slaves:1
slave0:ip=192.168.1.11,port=6379,state=online,offset=12345

此时，在主节点写入一条数据，在从节点立即读取，即可验证复制生效。

误区：从节点可以写数据。默认从节点是只读的（replica-read-only yes），但如果你手动改成可写，会导致数据不一致，且主从切换时可能丢失写入。除非有特殊需求，否则保持只读。
误区：主从复制是强一致的。实际上，主从复制是异步的，从节点可能落后主节点一段时间。如果业务要求强一致，需要引入其他机制（如WAIT命令），但会牺牲性能。
误区：多个从节点会拖垮主节点。从节点的全量同步会占用主节点的CPU、内存和网络，但增量同步开销较小。如果从节点太多，可以考虑级联复制（从节点下再挂从节点）。

当主节点宕机时，手动将一个从节点提升为主节点是常见的应急操作。步骤大致如下：

手动切换容易出错，生产环境建议使用高可用方案，如Redis Sentinel或Redis Cluster，它们能自动完成故障检测和切换。

复制延迟是监控的核心指标。在从节点执行INFO replication，其中的master_repl_offset和主节点的master_repl_offset差值即为延迟。通常延迟在毫秒级，如果持续增大，需要检查网络带宽或主节点写压力。

如果网络不稳定，可以适当增大repl-backlog-size，减少全量同步的概率。同时，建议开启repl-diskless-sync yes，让主节点直接通过网络发送RDB，减少磁盘I/O。

延伸阅读