redis怎样配置哨兵 redis哨兵模式的配置详解

Redis哨兵模式通过配置多个哨兵实例监控主从服务器，实现故障自动转移，保障高可用性。以下是详细配置步骤与关键要点：

一、配置步骤

准备Redis实例
至少需要3个Redis实例：1个主服务器（Master）、2个从服务器（Slave）。可根据需求增加从服务器数量。
配置主从复制
在从服务器的配置文件（redis.conf）中设置：slaveof <master-ip> <master-port>
重启从服务器生效，通过info replication命令验证复制状态。
配置哨兵实例
每个哨兵实例需独立配置文件（如sentinel1.conf、sentinel2.conf），关键参数如下：
端口：port 26379 # 默认端口，每个哨兵需唯一
监控主服务器：sentinel monitor <master-name> <master-ip> <master-port> <quorum># 示例：sentinel monitor mymaster 127.0.0.1 6379 2
quorum：判断主服务器失效所需的最小哨兵数量（如设为2，则至少2个哨兵同意才会触发故障转移）。
主观下线超时：sentinel down-after-milliseconds <master-name> 5000 # 5秒无响应视为主观下线
故障转移超时：sentinel failover-timeout <master-name> 180000 # 180秒内未完成转移视为失败
并行同步从服务器数：sentinel parallel-syncs <master-name> 1 # 每次故障转移时，仅1个从服务器同步新主
启动实例
启动顺序：主服务器 → 从服务器 → 哨兵实例。
启动哨兵命令：redis-sentinel /path/to/sentinel.conf
测试故障转移
手动停止主服务器，观察哨兵日志是否自动选举新主，并验证从服务器是否同步新主。

二、哨兵选举新主服务器的过程

主观下线（SDOWN）
单个哨兵检测到主服务器无响应超过down-after-milliseconds时间，标记为SDOWN。
客观下线（ODOWN）
当达到quorum数量的哨兵均标记主服务器为SDOWN时，触发ODOWN，启动故障转移。
选举领头哨兵
哨兵通过Raft算法选举领头哨兵，负责执行故障转移。
选择新主服务器
优先级：从服务器配置的slave-priority值越低优先级越高（默认100）。
复制偏移量：选择复制数据最完整的从服务器。
连接质量：优先选择与多数哨兵网络延迟低的从服务器。
执行故障转移
领头哨兵将选定的从服务器提升为新主，并通知其他从服务器复制新主。

三、监控哨兵运行状态

查看日志文件
哨兵日志记录故障转移、选举等关键事件，路径由配置文件中的logfile指定。
使用Redis客户端命令
连接哨兵后执行：SENTINEL masters # 列出所有被监控的主服务器SENTINEL slaves <master-name> # 查看指定主服务器的从服务器SENTINEL sentinels <master-name> # 查看其他哨兵实例
使用监控工具
Prometheus + Grafana：通过redis_exporter采集哨兵指标，可视化监控延迟、下线次数等。

四、客户端连接哨兵模式

配置哨兵地址列表
客户端需配置多个哨兵地址（如sentinel1:26379,sentinel2:26379），避免单点故障。
获取主服务器地址
客户端向哨兵发送命令：SENTINEL get-master-addr-by-name <master-name>
返回当前主服务器的IP和端口。
处理故障转移
客户端需监听哨兵通知或定期查询主地址，故障转移后自动重连新主。

五、哨兵模式的优缺点

优点
高可用性：自动故障转移，服务中断时间短。
自动发现：客户端通过哨兵动态获取主地址，无需手动更新配置。
监控通知：哨兵可集成邮件、Webhook等通知机制。
缺点
配置复杂：需合理设置quorum、超时时间等参数，避免误触发。
资源消耗：每个哨兵实例占用内存和CPU资源。
数据一致性风险：故障转移期间可能丢失少量写入操作（异步复制导致）。

六、最佳实践建议

通过以上配置，Redis哨兵模式可有效提升集群可用性，适用于对数据一致性要求较高的业务场景（如缓存、会话存储等）。

热门标签