平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Redis主从复制原理与配置做法”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

1. 引言

实际处理时，Redis 主从复制（Master-Slave Replication）是 Redis 高可用架构的基石。

结合项目来看，借助将一台主服务器（Master）的数据实时同步到一台或多台从服务器（Slave），能够完成数据冗余备份、读写分离以及故障恢复等能力。

结合项目来看，本文将从原理、设置、常用问题三个维度，系统讲解 Redis 主从复制的核心知识。

2. 为什么需主从复制

在单机 Redis 部署模式下，主要面临以下三个问题：

• 单点故障：一旦 Redis 进程崩溃或所在机器宕机，整个服务不可用，数据也可能丢失。这对我们的生产很不安全，一旦出现了问题便很难恢复。
• 读写压力集中：所有读写请求都落在同一台实例上，CPU、内存和网络带宽容易成为瓶颈。这样会严重影响反应的速度以及系统的流畅性。
• 数据安全风险：仅靠 RDB 或 AOF 持久化，无法完全避免磁盘损坏等极端情况下的数据丢失。

理解这一步时，主从复制借助将数据复制到多台从服务器，有效缓解了上述问题：从服务器能够作为热备份，也能够分担读请求，从而提升系统的整体可用性和扩展性。

3. 主从复制的工作原理

Redis 主从复制主要分为两个阶段：全量复制和增量复制。理解这两个阶段是掌握复制机制的关键。

3.1 全量复制

实际处理时，当从服务器首次连接主服务器，或从服务器与主服务器之间的断连时间过长导致复制偏移量（repl_offset）失效时，会触发全量复制。其流程如下所示：

1. 从服务器向主服务器发送 PSYNC 命令，请求同步数据。
2. 主服务器执行 BGSAVE 生成 RDB 快照文件，同时将新写入的命令记录在复制缓冲区（repl_backlog）中。
3. 在这个场景下，主服务器将 RDB 文件发送给从服务器，从服务器加载该文件，恢复数据快照。
4. 实际处理时，主服务器将复制缓冲区中积累的增量命令发送给从服务器，从服务器执行这些命令，最后与主服务器数据保持一致。

在这个场景下，全量复制会消耗较多的网络带宽和主服务器 CPU 资源，所以应尽量避免频繁触发。

3.2 增量复制

理解这一步时，当从服务器与主服务器短暂断连后重新连接，且复制偏移量仍在主服务器的 repl_backlog 缓冲区范围内时，会触发增量复制。主服务器只需将断连期间产生的增量命令发送给从服务器即可，效率远高于全量复制。

增量复制的核心依赖是 repl_backlog_size 参数，它决定了缓冲区的大小。如果缓冲区过小，断连期间产生的命令超出缓冲区容量，则会退化为全量复制。

4. 主从复制的设置方法

Redis 主从复制的设置很轻松，主要有以下三种方式。

4.1 借助设置文件设置

在从服务器的 redis.conf 设置文件中添加如下所示设置：

# 指定主服务器的 IP 和端口
replicaof 192.168.1.100 6379
如果主服务器设置了密码，需要配置
masterauth yourpassword

4.2 借助命令行动态设置

在从服务器启动后，能够借助 REPLICAOF 命令动态指定主服务器，无需重启进程：

# 在从服务器上执行
redis-cli> REPLICAOF 192.168.1.100 6379
取消复制，恢复为独立实例
redis-cli> REPLICAOF NO ONE

4.3 借助启动参数设置

也能够在启动从服务器时直接借助命令行参数指定主服务器：

redis-server --port 6380 --replicaof 192.168.1.100 6379

设置完成后，能够借助 INFO replication 命令查看复制状态，确认从服务器是否成功连接主服务器。

5. 主从复制的验证与监控

设置完成后，建议借助以下命令验证复制是否正常工作。

# 在主服务器上查看复制信息
redis-cli> INFO replication
# 输出示例
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6380,state=online,offset=12345,lag=0

理解这一步时，在从服务器上执行同样的命令，能够看到 role:slave 以及主服务器的连接信息。

落到代码里，此外，能够在主服务器写入一条数据，再到从服务器读取，验证数据是否同步成功。

6. 主从复制的常用问题与优化

6.1 复制延迟

落到代码里，主从复制是异步的，从服务器可能存在一定的数据延迟。对于读多写少的场景，能够借助以下方式降低延迟：

• 采用内网部署主从实例，减少网络传输耗时。
• 适当调大 repl-backlog-size，减少因缓冲区溢出导致的全量复制。
• 监控 lag 指标，及时发现问题。

6.2 从服务器只读

在这个场景下，默认情况下，从服务器是只读的，这样能够避免因误写入导致的数据不一致。如果确实需在从服务器上执行写操作，能够修改 replica-read-only 参数，但强烈不建议这样做。

落到代码里，我们的建议是在主节点上面进行写操作，从节点进行读的操作，这样分工明确，能够很好的协调好各部分的工作，同时且很好的规避数据不一致的问题。

6.3 主从数据一致性

实际处理时，由于复制是异步的，主服务器宕机时，尚未同步到从服务器的数据会丢失。如果业务对数据一致性要求极高，能够考虑采用 Redis Sentinel 或 Redis Cluster 提供的强一致方案，或引入 WAIT 命令等待从服务器确认写入。

7. 总结

理解这一步时，Redis 主从复制是构建高可用 Redis 服务的基础能力。借助本文的介绍，我们掌握了主从复制的全量复制与增量复制原理、三种设置方式以及常用问题的优化思路。

落到代码里，在实际生产环境里，建议将主从复制与 Redis Sentinel 哨兵机制结合采用，实现自动故障转移，进一步提升系统的可用性。

从实现思路看，总的来说，Redis主从复制适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。