Redis 主从架构与哨兵高可用方案实操

一、架构升级原理‌

1. 核心组件关系
   主从拓扑‌：每个主节点（Master）配置 1~N 个从节点（Slave），形成独立的主从复制单元
   哨兵监控网‌：哨兵集群监控所有主节点，通过 ‌分布式共识机制‌ 实现故障判定
   故障转移边界‌：单主节点故障仅影响其负责的从节点，其他主从单元不受影响
2. 数据同步机制
   主从复制‌：从节点通过 PSYNC 命令与主节点保持增量同步（默认异步复制）
   写安全策略‌：配置 min-replicas-to-write 1 确保主节点至少有 1 个从节点完成写入才响应客户端
   二、部署架构设计‌
3. 物理节点规划
   角色 IP 地址段 数量 端口 说明
   主节点 10.0.1.10~12 3 6379 数据写入节点
   从节点 10.0.1.20~22 3 6379 数据同步节点
   哨兵节点 10.0.1.30~32 3 26379 高可用监控集群
4. 逻辑拓扑示意
   plaintext
   Copy Code
   ±--------------+ ±--------------+ ±--------------+
   | 主节点1 | ←——→ | 从节点1 | | 哨兵集群 |
   | 10.0.1.10:6379| | 10.0.1.20:6379| | 10.0.1.30~32 |
   ±--------------+ ±--------------+ ±--------------+
   ↓
   ±--------------+ ±--------------+
   | 主节点2 | ←——→ | 从节点2 |
   | 10.0.1.11:6379| | 10.0.1.21:6379|
   ±--------------+ ±--------------+
   ↓
   ±--------------+ ±--------------+
   | 主节点3 | ←——→ | 从节点3 |
   | 10.0.1.12:6379| | 10.0.1.22:6379|
   ±--------------+ ±--------------+

三、详细配置实现‌

1. 主从节点配置

主节点配置文件 (redis-master.conf)‌:

conf
Copy Code
bind 0.0.0.0
port 6379
daemonize yes
requirepass maple168
masterauth maple168
repl-backlog-size 1gb # 增大复制缓冲区
min-replicas-to-write 1 # 写入最少从节点数

从节点配置文件 (redis-slave.conf)‌:

conf
Copy Code
replicaof 10.0.1.10 6379 # 指向对应主节点
masterauth maple168
repl-diskless-sync yes # 启用无盘复制（SSD环境建议开启）

2. 哨兵集群配置

统一配置文件 (sentinel.conf)‌:

conf
Copy Code
sentinel monitor master1 10.0.1.10 6379 2
sentinel monitor master2 10.0.1.11 6379 2
sentinel monitor master3 10.0.1.12 6379 2

sentinel auth-pass master1 maple168
sentinel auth-pass master2 maple168
sentinel auth-pass master3 maple168

sentinel down-after-milliseconds master1 5000 # 5秒无响应判宕机
sentinel parallel-syncs master1 1 # 故障转移时同步并发数

四、哨兵高可用流程‌

1. 故障检测阶段
   mermaid
   Copy Code
   sequenceDiagram
   哨兵A->>主节点1: 发送PING
   主节点1–>>哨兵A: 超时无响应
   哨兵A->>哨兵B: 发起主观下线(SDOWN)投票
   哨兵B->>主节点1: 独立检测
   哨兵B–>>哨兵A: 确认客观下线(ODOWN)

2. 领导选举阶段
   Raft 算法‌：哨兵节点通过 epoch 计数协商选出 Leader
   优先级规则‌：先发起投票的哨兵获得更高优先级

3. 故障转移执行
   mermaid
   Copy Code
   flowchart TB
   选择从节点 --> 检查复制偏移量
   检查复制偏移量 --> 最大偏移量节点
   最大偏移量节点 --> 晋升为新主
   通知其他从节点 --> 切换复制源

五、容器化集成方案‌

1. Docker Compose 模板
   yaml
   Copy Code
   services:
   redis-master1:
   image: redis:7.0
   command: redis-server /usr/local/etc/redis/redis.conf
   volumes:
   • ./master1.conf:/usr/local/etc/redis/redis.conf
     networks:
   • redis-net

redis-slave1:
image: redis:7.0
command: redis-server /usr/local/etc/redis/redis.conf
volumes:
- ./slave1.conf:/usr/local/etc/redis/redis.conf
depends_on:
- redis-master1

sentinel1:
image: redis:7.0
command: redis-sentinel /usr/local/etc/redis/sentinel.conf
volumes:
- ./sentinel.conf:/usr/local/etc/redis/sentinel.conf
ports:
- “26379:26379”

2. 关键网络配置
   bash
   Copy Code

创建 overlay 网络（跨主机通信）

docker network create --driver overlay --subnet 10.0.1.0/24 redis-net

六、监控与排障‌

1. 实时状态检查命令
   bash
   Copy Code

查看主从关系

redis-cli -a maple168 info replication

查看哨兵监控状态

redis-cli -p 26379 sentinel masters

强制触发故障转移（测试用）

redis-cli -p 26379 sentinel failover master1

2. 日志分析要点
   plaintext
   Copy Code

正常故障转移日志

+sdown master master1 10.0.1.10:6379 # 主观下线
+odown master master1 10.0.1.10:6379 # 客观下线
+try-failover master master1 # 尝试故障转移
+selected-slave slave1 10.0.1.20:6379 # 选择新主
+promoted-slave slave1 # 晋升从节点

3. 脑裂预防配置
   conf
   Copy Code

主节点配置（redis.conf）

min-replicas-to-write 1
min-replicas-max-lag 10 # 从节点延迟不超过10秒

七、性能压测数据‌
场景 QPS（读） QPS（写） 故障转移时间
单主从+哨兵 12万 8.5万 8-12秒
三主三从+哨兵 35万 24万 5-8秒
测试环境：16核/32GB 内存，SSD 磁盘，万兆网络

通过此方案，可在保障数据高可用的前提下实现 ‌横向扩展能力‌，每个主从单元可独立承担业务流量，哨兵集群提供跨节点的统一故障治理能力。