Redis 哨兵模式高可用配置

Redis哨兵模式高可用配置指南
在分布式系统中，Redis作为高性能的内存数据库，其高可用性至关重要。Redis哨兵模式（Sentinel）正是为此设计的一套自动故障转移解决方案，能够监控主从节点状态，并在主节点故障时自动选举新主节点，确保服务持续可用。本文将深入探讨哨兵模式的核心配置要点，帮助开发者构建稳定的Redis高可用架构。
哨兵模式基础配置
哨兵模式的核心是哨兵节点集群，通常建议部署至少3个哨兵实例以实现多数派决策。配置文件中需指定监控的主节点名称、IP和端口，并设置法定投票数（quorum）。例如，`sentinel monitor mymaster 127.0.0.1 6379 2`表示监控名为mymaster的主节点，当2个哨兵认为主节点不可达时触发故障转移。
故障检测与转移机制
哨兵通过定期PING命令检测节点健康状态。若主节点未响应超过`down-after-milliseconds`阈值（默认为30秒），哨兵会将其标记为“主观下线”。随后，其他哨兵确认该状态并达成“客观下线”共识，触发选举流程。选举依据包括从节点的复制偏移量、优先级等，最终选出新主节点并通知客户端更新配置。
客户端与哨兵交互
客户端需通过哨兵获取主节点信息，而非直连主库。主流Redis客户端（如Jedis、Lettuce）支持哨兵模式，配置时只需提供哨兵节点列表和主节点名称。客户端会定期从哨兵拉取最新拓扑，自动重定向到新主节点，实现无缝切换。哨兵发布的`+switch-master`事件可供订阅，便于业务层感知变更。
网络分区与脑裂防护
网络分区可能导致脑裂问题，即旧主节点仍可写入但与其他节点失联。哨兵通过`min-slaves-to-write`和`min-slaves-max-lag`参数防护：前者要求主节点至少同步到N个从节点才允许写入，后者限制同步延迟阈值。例如，设置`min-slaves-to-write 1`和`min-slaves-max-lag 10`可避免数据不一致风险。
通过合理配置哨兵参数、理解其故障转移逻辑，并结合客户端适配，开发者能够构建高可用的Redis服务，有效应对节点故障与网络异常，保障业务连续性。