2.1 把节点配置为 replica#

配置文件：

1
replicaof 192.168.10.10 6379

运行时命令：

1
REPLICAOF 192.168.10.10 6379

取消复制关系并把当前节点提升为独立 master：

1
REPLICAOF NO ONE

2.2 认证配置#

如果 master 需要认证，replica 必须配置连接 master 所需的凭证：

1
masterauth your-password

使用 ACL 时，还需要为复制连接配置具有相应权限的用户。生产环境应同时保护 master 和 replica，避免 replica 成为绕过认证的数据入口。

2.3 replica 的读写行为#

1
# 默认开启，只允许客户端读取 replica
2
replica-read-only yes
3

4
# 与 master 断开或正在同步时，是否允许返回可能过期的数据
5
replica-serve-stale-data yes

即使把 replica-read-only 改为 no，也不代表 Redis 变成多主系统：

• replica 上的本地写入不会反向复制给 master。
• 重新同步时，本地写入可能被 master 的数据覆盖。
• 普通主从架构应坚持所有业务写入只进入当前 master。

4.1 Replication ID#

Replication ID（复制 ID，通常称 replid）标识一段特定的数据历史。

• master 拥有自己的复制 ID。
• replica 同步后会记住 master 的复制 ID。
• 复制 ID 与 offset 组合起来，才能唯一描述某个数据历史中的位置。

Redis 还维护第二复制 ID：

• master_replid：当前复制历史。
• master_replid2：上一段复制历史。
• second_repl_offset：旧历史可以继续部分同步的边界。

第二复制 ID 主要用于故障转移后，让原 master 的其他 replica 仍有机会与新 master 进行部分同步。

4.2 Replication Offset#

复制偏移量表示复制流已经生成或处理到的位置。

• master 的 offset 随复制流增加。
• replica 保存自己已处理的 offset。
• 两者差值可以近似反映副本落后程度。

不能只比较 offset 而忽略复制 ID。不同复制历史中的相同 offset 没有可比性。

4.3 Replication Backlog#

Replication backlog 是 master 内存中的固定容量环形缓冲区，保存最近一段复制命令流。

它不是磁盘文件，正确配置名为：

1
repl-backlog-size 256mb

环形结构的特点：

1. 新复制数据持续写入 backlog。
2. 缓冲区写满后，从头覆盖最旧的数据。
3. replica 短暂断线后，可以根据 offset 获取缺失部分。
4. 如果需要的旧数据已被覆盖，就不能部分同步，只能全量同步。

文字示例：

1
backlog 保存的 offset 范围：10001 ～ 20000
2
master 当前 offset：       20000
3
replica 已处理 offset：    17500
4

5
结果：17501 ～ 20000 仍在 backlog 中，可以部分同步。

如果 replica 的 offset 是 8000，而 backlog 最早只保留到 10001，则缺失的 8001～10000 已经被覆盖，只能全量同步。

6.1 磁盘式全量同步#

完整时序：

1. replica 发送 PSYNC，请求继续原来的复制历史。
2. master 判断不能部分同步，回复进行全量同步。
3. master 启动后台保存，生成代表当前数据集的 RDB。
4. 生成 RDB 的同时，master 把新的写命令放入复制缓冲区。
5. master 把 RDB 传输给 replica。
6. replica 接收 RDB，清理旧数据并加载新数据集。
7. master 把生成 RDB 期间积累的命令继续发送给 replica。
8. replica 执行这些命令，追赶到 master 当前 offset。
9. 后续进入持续命令流复制。

1
Master                                   Replica
2
  │                                         │
3
  │ ←──── PSYNC replid offset ───────────── │
4
  │                                         │
5
  │ ───── FULLRESYNC new-replid offset ───→ │
6
  │                                         │
7
  │ 生成 RDB，同时缓存新写入                 │
8
  │ ─────────── RDB 数据流 ───────────────→ │
9
  │                                         │ 清空旧数据并加载 RDB
10
  │ ───── RDB 期间积累的命令流 ───────────→ │
11
  │ ───────── 持续复制命令流 ─────────────→ │

6.2 无盘复制#

1
repl-diskless-sync yes
2

3
# 等待一小段时间，让多个同时到来的 replica 共用一次同步
4
repl-diskless-sync-delay 5

无盘复制时，master 的子进程直接通过网络套接字把 RDB 数据流发送给 replica，而不先在 master 磁盘生成 RDB 文件。

优点：

• 避免 master 上的 RDB 磁盘写入。
• 适合磁盘较慢而网络较快的环境。
• 多个同时请求同步的 replica 可以共享一次 RDB 生成过程。

代价：

• 仍然需要 fork，仍存在 COW 内存开销。
• 会占用大量网络带宽。
• 网络慢或 replica 多时，子进程存活时间可能更长。
• 需要结合 repl-diskless-load 等配置评估 replica 的加载策略。

6.3 全量同步的主要成本#

因此应尽量避免多个大 replica 频繁触发全量同步。

9.1 全量同步会使用 RDB#

即使业务持久化配置中关闭了周期性 RDB，传统磁盘式全量复制仍可能生成 RDB 文件。

• 磁盘式复制：master 后台生成 RDB，再发送给 replica。
• 无盘复制：生成 RDB 格式的数据流并直接发送，不在 master 磁盘保留该文件。

所以“关闭 RDB 持久化”不等于“主从复制永远不会产生 RDB 相关开销”。

9.2 复制不能替代持久化#

复制的目标是让 replica 尽量成为 master 的当前副本。如果 master 变成空数据集，空数据也可能被复制出去。

危险场景：

1. master 关闭 RDB 和 AOF。
2. master 进程崩溃后被进程管理器自动重启。
3. 因为没有持久化，master 以空数据集启动。
4. replica 重新连接并把空 master 当作正确数据源。
5. replica 的原有数据被清空，整个复制组的数据一起丢失。

因此 Redis 官方建议：

• 使用复制时，在 master 和 replica 上开启适合业务的持久化。
• 如果 master 确实关闭持久化，不要让它在崩溃后未经人工确认就自动以空数据集重启。
• Sentinel 场景尤其要避免“无持久化 master + 自动重启”的组合。

9.3 replica 是否需要持久化#

通常建议 replica 也配置持久化，原因包括：

• replica 重启后可先从本地恢复，减少完全从 master 获取数据的风险。
• 某个 replica 可能在故障转移后成为新 master。
• 可把备份、RDB 归档等磁盘任务放到专用 replica，降低 master 压力。

但要注意：

• replica 的持久化文件同样会反映复制来的删除和误操作。
• replica 本地持久化仍不是独立、版本化的备份。
• Redis 官方文档指出，replica 平滑停机时写入的 RDB 可以保存部分同步所需元数据；仅通过 AOF 重启的 replica 不能依靠 AOF 完成相同的部分同步恢复。

9.4 AOF 与复制流不是同一个概念#

10.1 使用 min-replicas 限制风险#

1
min-replicas-to-write 1
2
min-replicas-max-lag 10

含义：

• 至少需要 1 个 replica 满足最大延迟要求。
• 如果 master 在规定时间内没有收到足够 replica 的进度确认，则停止接受写入。

作用：

• 限制 master 与 replica 长时间失联时继续产生大量孤立写入。
• 缩小网络分区期间的数据分叉窗口。

代价：

• replica 不满足条件时，master 会拒绝写入，可用性下降。
• 这仍不是严格同步复制，也不能保证绝对零丢失。

10.2 使用 WAIT 提高关键写入安全性#

1
SET order:1 paid
2
WAIT 1 1000

WAIT 1 1000 表示最多等待 1000 毫秒，希望至少 1 个 replica 确认已经接收到当前连接此前的写入。

应用必须检查返回值：

1
返回 1：至少一个 replica 已确认相应复制位置
2
返回 0：超时前没有 replica 满足条件

注意：

• WAIT 提高写入已到达 replica 的概率，但不会把 Redis 变成强一致 CP 系统。
• replica 确认复制 offset 不一定等于写入已经按目标策略落到磁盘。
• WAIT 不能替代 AOF、RDB、备份或正确的故障转移设计。
• 执行 WAIT 后若业务从另一个落后 replica 读取，仍可能读到旧值；读路由也必须设计。

12.1 控制单节点数据量#

单节点数据集越大：

• 全量同步的 RDB 越大。
• fork、COW、网络传输和加载时间越长。
• replica 追赶期间积累的命令越多。
• 故障恢复 RTO 越长。

应通过合理分片、内存上限和容量规划控制单节点规模。

12.2 合理增大 backlog#

backlog 应覆盖常见网络抖动和滚动重启时间，避免短暂断线退化为全量同步。

不要盲目设置：

• 太小：频繁全量同步。
• 太大：浪费 master 内存。
• 应基于峰值复制流量和最长断线时间计算。

12.3 评估无盘复制#

磁盘慢、网络快时可考虑：

1
repl-diskless-sync yes
2
repl-diskless-sync-delay 5

但仍需压测网络、COW 内存和多个 replica 同步时的表现。

12.4 限制直接 replica 数量#

大量 replica 同时直接连接 master 会增加：

• 网络输出。
• 每个 replica 的客户端输出缓冲区。
• 心跳和状态维护。
• 故障时的同步风暴。

可以采用级联复制降低 master 压力，但要评估多一跳延迟和级联上游故障的影响。

12.5 避免同步风暴#

• 分批重启 replica。
• 配合 repl-diskless-sync-delay 合并相近的同步请求。
• 不让大量 replica 在同一时间失联和重连。
• 监控全量同步次数与网络出口带宽。
• Sentinel 中合理配置并行同步数量，避免故障转移后所有 replica 同时加载。

13.1 查看复制状态#

1
redis-cli INFO replication
2
redis-cli ROLE

master 侧重点：

• role
• connected_slaves：为兼容保留的旧字段名，表示已连接 replica 数。
• master_replid
• master_replid2
• master_repl_offset
• second_repl_offset
• repl_backlog_active
• repl_backlog_size
• repl_backlog_first_byte_offset
• repl_backlog_histlen

replica 侧重点：

• master_host
• master_port
• master_link_status
• master_last_io_seconds_ago
• master_sync_in_progress
• slave_repl_offset：兼容旧协议保留的字段名。
• slave_read_repl_offset
• master_link_down_since_seconds

还应结合：

1
redis-cli INFO persistence
2
redis-cli INFO memory
3
redis-cli INFO stats
4
redis-cli LATENCY DOCTOR

13.2 常见故障判断表#

Master#

1
# 持久化
2
appendonly yes
3
appendfsync everysec
4
save 3600 1
5

6
# 部分同步窗口
7
repl-backlog-size 1gb
8
repl-backlog-ttl 3600
9

10
# 全量同步
11
repl-diskless-sync yes
12
repl-diskless-sync-delay 5
13

14
# 限制失去副本后的孤立写入
15
min-replicas-to-write 1
16
min-replicas-max-lag 10

Replica#

1
replicaof 192.168.10.10 6379
2
masterauth your-password
3

4
replica-read-only yes
5
replica-serve-stale-data yes
6

7
# 作为可能被提升的新 master，通常也应具备持久化能力
8
appendonly yes
9
appendfsync everysec

部署时还要补充：

• ACL 或密码配置。
• TLS 复制链路。
• 主机地址通告与 NAT 环境配置。
• Sentinel 或 Cluster 故障转移。
• 跨可用区延迟与带宽评估。
• 备份、告警和恢复演练。