【Redis】redis主从哨兵

Redis 主从复制

在访问量极高的场景下，单台 Redis 已难以承载全部请求，且单点故障风险高。通过主从复制，可以实现读写分离、数据备份与高可用。
概念

• 主节点（Master）：负责写操作，将数据变动同步给从节点。
  
• 从节点（Slave/Replica）：负责读操作，主动从主节点拉取最新数据。
  

上风

• 性能提升：读请求分摊到多个从节点
  
• 数据备份：从节点持有一份完备数据副本
  
• 读写分离：写入在主节点，读取在从节点
  
• 进步可靠性：主节点故障后，从节点仍可提供读取服务
  

---

搭建主从复制集群

可以用两台机器，也可在一台机器上启动多个 Redis 实例，只需用不同设置文件。
通用设置（主从共用）

1. requirepass 123456
2. loglevel notice
3. pidfile /var/run/redis_6379.pid
4. logfile "/var/log/redis/redis6379.log"
5. dbfilename dump.rdb
6. dir /var/lib/redis-slave6379
7. bind 0.0.0.0
8. port 6379
9. daemonize yes

复制代码

从节点额外设置

1. masterauth 123456
2. replicaof 192.168.100.30 6379

复制代码

• 先启动主节点，再启动从节点。
  
• 验证主从状态：
  
  1. # 主节点
  2. 192.168.100.30:6379> info replication
  3. role:master
  4. connected_slaves:2
  5. ...
  7. # 从节点
  8. 192.168.100.200:6389> info replication
  9. role:slave
  10. master_host:192.168.100.30
  11. master_link_status:up
  12. ...

  复制代码
• 测试读写
  
  
  
  • 主节点：可读可写
    
  • 从节点：只读，写入会报 READONLY You can't write against a read only replica.
    
  
  
• 断线重连
  如果从节点短暂断开，重新上线后会主动补同步这段时间的全部数据，不会丢失。
  
• 故障规复
  主节点宕机，从节点不会主动“上位”。需人工或由哨兵进行故障转移。
  

---

主从从拓扑

当主节点被大量从节点挂载压力过大时，可使用“主→从→从”多级复制。

1. # 从节点命令示例，将当前实例从现有主切到新的主
2. 192.168.100.200:6389> SLAVEOF 192.168.100.200 6379

复制代码

  注意：多级复制会引入更高的耽误。
  

---

退出从模式（无停机）

如果临时必要让某个从节点切换为主：

1. 192.168.100.200:6389> SLAVEOF no one
2. OK
3. 192.168.100.200:6389> info replication
4. role:master
5. connected_slaves:0
6. ...

复制代码

日志中会看到从节点断开主节点毗连并开启主模式的记录。

---

主从复制工作流程

• 从节点启动 → 毗连主节点 → 发送 SYNC（或 PSYNC）下令
  
• 主节点
  
  
  
  • 收到同步请求后后台生成一次完备的 RDB 快照
    
  • 将快照数据发送给从节点
    
  • 在生成快照期间及之后，将新的写下令缓存在内存并实时转发给从节点
    
  
  
• 心跳
  
  
  
  • 默认每 10 秒发送一次 PING 确保主从毗连正常，可通过 repl-ping-replica-period 调解
    
  
  

---

Redis 哨兵（Sentinel）

Sentinel 负责监控主从集群康健，主动故障转移并通知客户端。
Sentinel 核心功能

• 主从监控：实时检测主、从节点是否可用
  
• 故障通知：将故障及切换效果告知客户端
  
• 主动故障转移：主节点挂掉时，选举新的主节点并重设置全部从节点
  
• 设置中央：主动更新 Redis 和 Sentinel 的设置文件
  

部署示例

• 预备一主二从，分别启动：
  
  1. redis-server /etc/redis6379.conf   # 主
  2. redis-server /etc/redis6389.conf   # 从1
  3. redis-server /etc/redis6399.conf   # 从2

  复制代码
• 设置并启动三台 Sentinel（发起奇数台）：
  
  1. bind 0.0.0.0
  2. protected-mode no
  3. port 26379
  4. daemonize yes
  5. pidfile /var/run/redis-sentinel26379.pid
  6. logfile "/redisdata/sentinel26379.log"
  7. dir /redisdata
  9. sentinel monitor mymaster 192.168.100.131 6379 2
  10. sentinel auth-pass mymaster 123456

  复制代码
  启动下令任选其一：
  
  1. redis-sentinel /etc/sentinel26379.conf
  2. # 或
  3. redis-server /etc/sentinel26379.conf --sentinel

  复制代码
• 查看 Sentinel 日志，确认监控已见效。
  

---

故障转移流程

• 主观宕机判定（Sentinel 认为主不可达），标记 +sdown
  
• 投票：至少 quorum 台 Sentinel 同意
  
• 客观宕机确认，标记 +odown
  
• 设置更新：Sentinel 更新自身及 Redis 实例设置
  
• 切换主节点，+switch-master
  
• 旧主规复：如果旧主重启，按设置会被设为从节点，不再主动成为主
  

1. 186501:X 19 Apr 2025 12:13:52.675 # +sdown master mymaster 192.168.100.30 6379
2. 186501:X 19 Apr 2025 12:13:52.736 # +new-epoch 1
3. 186501:X 19 Apr 2025 12:13:52.737 # +vote-for-leader 8e9617be2327ed19c589ee819bc725eb892ad700 1
4. 186501:X 19 Apr 2025 12:13:52.747 # +odown master mymaster 192.168.100.30 6379 #quorum 3/2
5. 186501:X 19 Apr 2025 12:13:53.874 # +switch-master mymaster 192.168.100.30 6379 192.168.100.200 6389

复制代码

这些日志行展示了完备的故障转移过程：

• 首先检测到主节点宕机（+sdown）
  
• 开始新的选举周期（+new-epoch）
  
• 投票给指定的哨兵领导者（+vote-for-leader）
  
• 确认主节点客观宕机（+odown）
  
• 最终完成主节点切换（+switch-master），将主节点从192.168.100.30:6379切换到192.168.100.200:6389
  

常见题目排查

• 网络连通：防火墙、端口、SELinux 是否放行/关闭
  
• 认证密码：主从与 Sentinel 之间密码需同等
  
• 日志检查：从节点或 Sentinel 日志中有无错误提示
  
• 资源瓶颈：Redis 实例的 CPU、内存、磁盘 IO 是否到达上限
  

---

   小贴士：生产环境中发起团结 Redis Cluster 或者更美满的高可用方案，根据业务需求选择合适的架构。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。