redis主从复制

Redis 主从复制原理及线上实现方案

一、Redis 主从复制原理

Redis 主从复制（Master-Slave Replication）是 Redis 实现高可用和读写分离的基础机制，通过将主节点（Master）的数据异步复制到从节点（Slave），实现数据备份和负载分担。其核心原理如下：

1. 复制流程

主从复制分为 初始化同步 和 增量同步 两个阶段：

• 初始化同步（全量复制）
  当从节点首次连接主节点，或从节点断开后重新连接且无法进行增量同步时，触发全量复制：

  1. 从节点向主节点发送 SYNC 命令（Redis 2.8 前）或 PSYNC 命令（Redis 2.8+，支持部分重同步）。
  2. 主节点收到命令后，执行 bgsave 生成 RDB 快照，并缓存此过程中产生的写命令（通过缓冲区记录）。
  3. 主节点将 RDB 文件发送给从节点，从节点接收后清空本地数据，加载 RDB 恢复数据。
  4. 主节点将缓存的写命令发送给从节点，从节点执行这些命令，确保与主节点数据一致。

• 增量同步
  全量复制完成后，主节点每产生一条写命令（如 SET、HSET），会异步将命令发送到从节点，从节点执行命令保持数据同步。

  • 主节点维护 复制偏移量（replication offset）：记录自身发送的字节数。
  • 从节点维护 复制偏移量：记录自身接收的字节数。通过对比偏移量，主从可判断数据是否一致。
  • 主节点还维护 复制积压缓冲区（replication backlog buffer）：一个固定大小的环形缓冲区（默认 1MB），用于暂存最近的写命令。当从节点短暂断开后重连，可通过偏移量从缓冲区获取缺失的命令，避免全量复制。

2. 核心特性

• 异步复制：主节点发送命令后无需等待从节点确认，继续处理其他请求（性能优先）。
• 读写分离：主节点负责写操作，从节点负责读操作（通过 slave-read-only yes 配置从节点只读）。
• 级联复制：从节点可作为其他从节点的主节点（减轻主节点复制压力）。

二、线上主从复制实现步骤

以下以 Redis 6.2 为例，基于 Linux 环境（如 CentOS 7）实现一主两从架构（1 主 2 从），适用于生产环境。

环境准备

角色	IP 地址	端口	备注
Master	192.168.1.100	6379	主节点，接收写请求
Slave1	192.168.1.101	6379	从节点 1，负责读请求
Slave2	192.168.1.102	6379	从节点 2，负责读请求/备份

• 前置条件：
  • 所有节点 Redis 版本一致（避免兼容性问题）。
  • 关闭防火墙或开放 6379 端口（或自定义端口）：

    firewall-cmd --zone=public --add-port=6379/tcp --permanent
    firewall-cmd --reload
    

  • 主节点已配置密码（requirepass），从节点需知道主节点密码才能连接。

步骤 1：配置主节点（Master）

1. 修改主节点配置文件（redis.conf，默认路径 /etc/redis/redis.conf 或 /usr/local/redis/conf/redis.conf）：

   # 绑定本地 IP（生产环境建议绑定具体 IP，而非 0.0.0.0）
   bind 192.168.1.100
   port 6379
   
   # 开启持久化（避免主节点宕机后数据丢失，可选 RDB 或 AOF）
   save 900 1    # 900 秒内有 1 次写操作则触发 RDB
   save 300 10   # 300 秒内有 10 次写操作则触发 RDB
   appendonly yes  # 开启 AOF 持久化（更安全）
   
   # 设置访问密码（生产环境必须配置）
   requirepass Redis@123456
   
   # 允许从节点连接（默认开启，无需修改）
   replica-announce-ip 192.168.1.100  # 向从节点宣告自身 IP（可选，多网卡场景必配）
   

2. 启动主节点：

   # 后台启动
   redis-server /etc/redis/redis.conf &
   # 确认启动成功
   redis-cli -h 192.168.1.100 -p 6379 -a Redis@123456 ping
   # 输出 PONG 表示正常
   

步骤 2：配置从节点（Slave1/Slave2）

以 Slave1（192.168.1.101）为例，Slave2 配置相同（仅 IP 不同）。

1. 修改从节点配置文件（redis.conf）：

   # 绑定从节点 IP
   bind 192.168.1.101
   port 6379
   
   # 开启只读模式（禁止从节点写操作，生产环境必须配置）
   slave-read-only yes  # Redis 5.0+ 改为 replica-read-only yes
   
   # 配置主节点信息
   replicaof 192.168.1.100 6379  # Redis 5.0+ 用 replicaof，旧版本用 slaveof
   masterauth Redis@123456       # 主节点的访问密码
   
   # 向其他节点宣告自身 IP（级联复制场景必配）
   replica-announce-ip 192.168.1.101
   
   # 持久化配置（建议与主节点一致，可选）
   appendonly yes
   

2. 启动从节点：

   redis-server /etc/redis/redis.conf &
   # 确认启动成功
   redis-cli -h 192.168.1.101 -p 6379 -a Redis@123456 ping
   

步骤 3：验证主从复制状态

1. 查看主节点信息：
   在主节点执行 info replication，查看从节点连接状态：

   redis-cli -h 192.168.1.100 -p 6379 -a Redis@123456 info replication
   

   输出示例（关键部分）：

   # Replication
   role:master
   connected_slaves:2  # 有 2 个从节点连接
   slave0:ip=192.168.1.101,port=6379,state=online,offset=100,lag=1
   slave1:ip=192.168.1.102,port=6379,state=online,offset=100,lag=1
   

2. 查看从节点信息：
   在从节点执行 info replication，确认角色为 slave 且主节点信息正确：

   redis-cli -h 192.168.1.101 -p 6379 -a Redis@123456 info replication
   

   输出示例（关键部分）：

   # Replication
   role:slave
   master_host:192.168.1.100
   master_port:6379
   master_link_status:up  # 与主节点连接正常
   master_last_io_seconds_ago:1  # 最近一次通信时间
   slave_repl_offset:100  # 复制偏移量（与主节点一致）
   

3. 数据同步测试：

   • 在主节点写入数据：

     redis-cli -h 192.168.1.100 -p 6379 -a Redis@123456 set test_key "hello replication"
     

   • 在从节点读取数据，确认同步成功：

     redis-cli -h 192.168.1.101 -p 6379 -a Redis@123456 get test_key
     # 输出 "hello replication"
     

步骤 4：配置级联复制（可选）

若主节点压力过大，可将其中一个从节点作为其他从节点的主节点（级联复制），减轻主节点负担。
例如，让 Slave2 以 Slave1 为父节点：

1. 修改 Slave2 的 redis.conf：

   replicaof 192.168.1.101 6379  # 改为指向 Slave1
   masterauth Redis@123456       # 若 Slave1 也配置了密码，需填写其密码
   

2. 重启 Slave2，验证：
   在 Slave1 执行 info replication，应显示 connected_slaves:1（Slave2 连接）。

三、线上部署注意事项

1. 性能优化

   • 主节点：关闭不必要的持久化（如仅用 AOF 或 RDB），避免 bgsave 阻塞；配置 repl-backlog-size 增大复制积压缓冲区（如 repl-backlog-size 10mb，减少全量复制概率）。
   • 从节点：开启 slave-read-only yes 防止误写；配置 repl-diskless-sync yes 启用无盘复制（避免 RDB 文件写入磁盘，适合网络好的场景）。

2. 高可用配置

   • 结合 Redis Sentinel（哨兵）实现主从自动故障转移（当主节点宕机，哨兵自动将从节点升级为主节点）。
   • 主从节点跨机房部署，避免单机房故障导致数据丢失。

3. 监控告警

   • 通过 info replication 监控关键指标：master_link_status（连接状态）、connected_slaves（从节点数量）、slave_repl_offset（偏移量延迟）。
   • 用 Prometheus + Grafana 或 Redis Exporter 监控，设置告警（如主从连接断开、延迟超过 1000ms）。

4. 安全加固

   • 所有节点配置强密码（requirepass 和 masterauth）。
   • 限制 bind 地址，仅允许信任的 IP 访问。
   • 禁用危险命令（如 FLUSHALL、KEYS）：在 redis.conf 中配置 rename-command FLUSHALL ""。

5. 容灾备份

   • 从节点定期备份 RDB/AOF 文件（如每日备份到对象存储）。
   • 主节点开启 AOF 重写（auto-aof-rewrite-percentage 100），避免 AOF 文件过大。

四、常见问题及解决

1. 从节点无法连接主节点

   • 检查主节点密码是否正确（masterauth 配置）、网络是否通畅（telnet 192.168.1.100 6379）、主节点 bind 是否限制了从节点 IP。

2. 主从数据延迟过大

   • 原因：主节点写入压力高、从节点性能不足、网络延迟。
   • 解决：拆分主节点写请求、升级从节点硬件、增大 repl-backlog-size、开启从节点并行复制（slave-parallel-reads 4，Redis 6.0+ 支持）。

3. 全量复制频繁触发

   • 原因：从节点断开时间过长（超过 repl-backlog-size 缓存）、主节点 bgsave 失败。
   • 解决：调大 repl-backlog-size、确保主节点有足够内存执行 bgsave（避免 OOM）、减少从节点断开次数。

通过以上步骤，可在生产环境搭建稳定的 Redis 主从复制架构，结合哨兵或集群可进一步提升可用性。核心是确保主从配置一致、监控及时、故障可自动转移。