1. 部署与架构概览
1.1 目标与整体架构
在企业级应用中，Redis Sentinel 提供了对主从结构的自动化监控与故障转移能力，帮助实现高可用性和最小化的业务中断。核心架构通常由一个或多个主节点、若干从节点，以及若干 Sentinel 进程组成，形成一个协同工作的监控-选举-故障转移闭环。通过这种分布式协作，系统在主节点下线时能够快速选举新主并将写请求重新路由。部署目标是让服务在单点故障发生时尽量无感知地继续运行，确保数据在持续写入中的一致性与可用性。
在实际落地中，常见的拓扑为：1 个或多个主节点，若干只读从节点，以及至少 3 个 Sentinel 实例，以实现足够的投票阈值和容错能力。通过分布式节点的地理分布，可以提升对局部网络波动的鲁棒性，并降低故障对全局业务的影响。高可用配置的核心在于正确的监控、合适的选举阈值以及健壮的故障转移流程。
1.2 部署拓扑与角色分工
典型拓扑中，主节点承载写负载并向从节点异步复制数据；从节点为读写分离提供副本服务，提升读取吞吐量与故障切换的平滑性。哨兵（Sentinel）负责持续监控主从健康、维护信息、并在达成多数同意后触发故障转移。为确保可用性，部署时应遵循如下原则：多区域部署以防单区域故障、奇偶分布避免同区域同时故障、以及网络端口与防火墙策略的一致性。
1.3 部署准备清单
在正式启用前，需要确保网络连通性、服务器资源、时钟同步以及持久存储的可靠性。时钟对齐对复制和故障转移的一致性至关重要，建议使用 NTP；持久化配置确保数据不会因进程重启而丢失。
2. Redis Sentinel 核心概念
2.1 监控对象、投票与故障检测
监控对象通常是 Redis 主节点及其主从关系，Sentinel 会定期检查主节点是否可达、复制是否正常，以及从节点的复制状态。投票机制要求至少达到设定的 quorum（法定人数）才能触发故障转移，确保在分区情况下不会误判。
当探测到主节点不可用时，Sentinel 会把该信息传播给同组的其他 Sentinel，并对当前的主副本状态进行一致性判断。若超过阈值，故障转移流程将进入选举阶段，选出新的主节点并通知所有从节点重定向写入。
2.2 选举、重定向与一致性
选举过程通过投票实现，投票通常依赖于 master-id、IP、端口等元信息，并以多数派作为最终的领导者。故障转移完成后，新的主节点将获得写入权限，原主节点在数据同步完成前成为从节点等待续传。写请求路由通过 Sentinel 决定的新主来完成，确保客户端无需感知切换。
3. Sentinel 配置与部署步骤
3.1 部署前提与系统要求
在正式启用前，需确保每个 Redis 实例具备稳定的网络、充足的磁盘 IOPS，以及合适的内存容量。一致的时钟同步是实现精确故障判断的重要条件，推荐统一使用 NTP。
为了实现高可用，通常会部署不少于 3 个 Sentinel 实例并放置在不同的物理节点。独立端口和安全访问控制可减少跨节点通信的风险。
3.2 sentinel.conf 关键配置项
以下配置项是 Sentinel 的核心，掌握它们有助于快速搭建稳定的高可用环境：monitors、down-after-milliseconds、failover-timeout、parallel-syncs 等。
# sentinel.conf（示例）
port 26379
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1
其中 sentinel monitor 指定了要监控的主节点信息与投票阈值，down-after-milliseconds 定义检测下线的超时时间，failover-timeout 限制故障转移的最长时间，parallel-syncs 控制从节点与新主节点之间的并行复制数量。
3.3 启动与自检命令
启动 Sentinel 集群通常以独立进程启动为佳，确保每个实例的日志可追溯。启动后应执行自检，验证 Sentinel 是否正确连接到目标主节点、从节点及其他 Sentinel。redis-sentinel 的日志中应出现正常的仲裁和对主从状态的更新信息。
4. 故障转移流程与监控
4.1 故障检测与投票触发
当主节点不可用且 达到 quorum 时，Sentinel 将进入故障转移流程。此时，健康检查结果一致性是关键，以避免错误地切换到不可用的副本。
监控系统应持续记录主从状态、从节点延迟、网络分区情况等指标，以便在需要时能够快速定位问题并回滚。
4.2 选主、重定向写入与客户端重定向
故障转移完成后，新主节点将被写入路由更新，客户端需要通过 Sentinel 服务发现新的主节点地址或端口。此过程对应用透明，确保读写分离策略与前端负载均衡保持一致。
在某些场景下，运维人员会执行手动干预以确保数据同步完整性，此时需要监控复制偏差与从节点的同步进度，确保最终一致性。
4.3 故障转移后的验证与回滚策略
完成故障转移后，应立即进行功能性测试，验证写入能正常落盘、从节点能够继续同步新主信息。若出现异常，应具有回滚策略，例如将从节点重新指向原主并在网络恢复后再次触发自动故障转移。
5. 监控、告警与日常运维
5.1 指标、告警与日志设计
可关注的关键指标包括：sentinel 状态有效性、主从延迟、故障转移次数、投票时延、以及网络分区情况。通过统一的日志等级与集中化日志平台，可以实现快速告警和事后追踪。
对于告警策略，建议设置阈值告警与趋势告警相结合，避免误报，同时确保在异常累计时触发自动化处理。
5.2 脚本化运维与自动化
通过脚本可以实现对 Sentinel 集群的健康自检、滚动更新与自动化回滚。下面给出一个简单的健康检查脚本示例思路：检查 sentinel 主从状态、验证 failover 状态，并在异常时发送告警。
#!/bin/bash
# 简单健康检查示例（伪代码）
for host in sentinel01 sentinel02 sentinel03; doredis-cli -p 26379 INFO | grep -E 'sentinel_lines|sentinel_master'
done
实际环境中应将脚本与监控平台对接，使用 REST API 触发告警或自动化运维流程，以提升响应速度。
6. 安全集群与扩展性
6.1 安全性与认证
为避免未授权的故障转移触发，应启用相应的访问控制，例如在网络分区时使用私有网络、对管理端口设定防火墙策略、并结合 TLS/加密通道保障 Sentinel 与 Redis 的通信安全。认证与加密能够降低中间人攻击和凭据泄露的风险。
在可能的情况下，采用基于证书的双向认证，并将 Sentinel 配置中可能暴露的敏感信息进行最小化暴露。
6.2 拓扑扩展与容量规划
随着业务增长，应评估主节点的写入压力和从节点的复制延迟，合理扩展节点数量并调整投票阈值，以确保在分区场景下仍能维持正确的故障转移。容量规划应包含 Redis 数据持久化策略、AOF 重写策略以及网络带宽资源分配。
