Redis实现哨兵模式

Redis Sentinel 高可用方案：原理、部署与实战指南

一、为什么需要 Sentinel？

在分布式系统中，Redis 作为高性能的内存数据库，其可用性直接影响业务稳定性。当主节点宕机时，传统方案面临以下问题：

1. 手动切换延迟：运维介入需要时间，可能造成服务中断

2. 配置一致性：客户端需要手动更新连接信息

3. 脑裂风险：主从切换过程中可能出现数据冲突

Redis Sentinel 正是为解决这些问题而生的高可用解决方案，它提供：

• 自动故障检测与转移

• 配置中心化管理

• 客户端自动发现

二、Sentinel 核心架构

1. 组件构成

图表

代码

2. 关键角色

• Sentinel节点：独立进程，不存储数据，仅负责监控和决策

• Master：写入节点（唯一可写）

• Replica：复制节点（只读）

三、部署实战（3节点示例）

1. 配置文件示例

sentinel.conf 核心配置：

ini

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 30000
sentinel parallel-syncs mymaster 1

参数说明：

• quorum 2：至少需要2个Sentinel同意才能触发故障转移

• down-after-milliseconds：判定不可用的超时时间

• parallel-syncs：故障转移后同时同步的新副本数量

2. 启动命令

bash

# 启动Sentinel集群（每个节点）
redis-server /path/to/sentinel.conf --sentinel

# 验证节点状态
redis-cli -p 26379 info sentinel

3. 节点发现机制

Sentinel 启动后自动执行以下流程：

1. 连接配置中指定的 Master

2. 获取 Master 的副本信息

3. 通过 Pub/Sub 自动发现其他 Sentinel

四、故障转移全流程

1. 故障检测阶段

图表

代码

2. 故障转移阶段

1. Leader选举：使用Raft算法选出主导Sentinel

2. 新Master选择：根据规则选择最优副本：

   • 副本优先级（replica-priority）

   • 复制偏移量最大

   • Run ID 字典序最小

3. 配置传播：更新所有节点的sentinel.conf

3. 客户端重定向

java

// Jedis 客户端示例
JedisSentinelPool pool = new JedisSentinelPool(
    "mymaster", 
    Set.of("sentinel1:26379", "sentinel2:26379")
);

五、生产环境最佳实践

1. 部署建议

• Sentinel节点数：至少3个且部署在不同物理机

• 网络配置：禁用THP，优化内核参数

bash

echo never > /sys/kernel/mm/transparent_hugepage/enabled

2. 监控指标

关键监控项：

bash

# 获取监控数据
redis-cli -p 26379 info

# 重要指标
sentinel_masters:1
sentinel_tilt:0
master0:status=ok,slaves=2,sentinels=3

3. 常见问题处理

问题1：脑裂场景

• 现象：两个Master同时接受写入

• 解决方案：

  ini

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

问题2：配置不一致

• 修复命令：

  bash

  redis-sentinel /path/to/sentinel.conf --sentinel reset <master-name>

六、性能优化方案

1. 参数调优

ini

# 减少误判概率
sentinel down-after-milliseconds mymaster 8000

# 加速故障转移
sentinel failover-timeout mymaster 180000

2. 客户端优化

java

// Lettuce 客户端配置
ClientOptions options = ClientOptions.builder()
    .autoReconnect(true)
    .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS)
    .build();

七、与Cluster模式对比

八、总结

Redis Sentinel 在以下场景表现优异：

• 需要高可用的单点Redis部署

• 业务数据量未达到分片需求

• 运维资源有限的场景

最终建议：对于关键业务系统，建议 Sentinel + Keepalived 组合使用，实现VIP漂移，达到更高可用性。