1. 架构要点
1.1 Redis Sentinel 架构核心组件
在Redis Sentinel的高可用配置中，核心组件包括多个 Sentinel 实例、一个或多个 Redis 主从复制节点，以及它们之间的通信机制。Sentinel 实例负责监控、通知和故障转移决策，从而实现对主节点的自动发现与重新指向。通过分布式部署，系统的故障检测与转移不会依赖单点，从而提升总体可靠性。
架构设计强调哨兵与被监控 Redis 实例的解耦，Sentinel 以独立进程运行，监控主从复制的健康状况并维护一个监控名单。当主节点故障时，Sentinel 通过多数投票达成一致，从而触发对新主的选举与配置调整，保证服务持续可用。
在实际部署中，常见的架构包括一主多从的复制拓扑，以及多组 Sentinel 实例共同构成高可用守护网。通过跨节点的心跳与通信，Sentinel 能快速感知网络分区、节点不可达等异常并启动故障转移流程。
# sentinel.conf 示例片段
port 26379
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
1.2 监控与故障检测原理
Sentinel 的监控基于对被监控 Redis 实例的定期健康检查，包括 PING、INFO、REPL 状态等指标。down-after-milliseconds 参数用来定义检测主节点“不可用”的时间阈值，一旦超过阈值，Sentinel 会将该节点标记为 趋于不可用 的状态。
当多个 Sentinel 实例对同一主节点达成一致时，系统进入故障切换的初步阶段，这个阶段通常伴随对现有副本的重新配置与客户端路由的更新。告警与通知机制确保运维在自动化流程之外也能得到即时信息。
此外，Sentinel 还设计了对客户端的无缝告知，通过 SENTINEL 命令集帮助客户端获取当前主节点信息或新主地址，从而在故障切换后快速恢复业务流量。
# sentinel.conf 相关参数解释
# 1) 监控目标 master 的名称、地址和端口
sentinel monitor mymaster 127.0.0.1 6379 2
# 2) 主节点下线后等待时间（毫秒）
sentinel down-after-milliseconds mymaster 5000
# 3) 故障转移的超时时间
sentinel failover-timeout mymaster 10000
# 4) 同一时刻并行的同步副本数量
sentinel parallel-syncs mymaster 1
1.3 选举与主备切换机制
在 Redis Sentinel 的高可用配置中，故障发生时需要多方一致的投票来决定是否执行故障转移。多数同意原则确保即使部分 Sentinel 失效，系统仍能保持可用性。通过投票，Sentinel 会选出一个 新主，并指示从节点更新为新的主地址。
选举过程通常包含对当前副本的提升、将其他从节点指向新主的配置以及对客户端的更新通知。主从复制关系的重新建立确保数据继续以正确的路径写入与同步。
对于开发与运维团队来说，理解 SENTINEL get-master-addr-by-name 以及 SENTINEL MASTER 的返回信息，是诊断与排错的基础能力。下面展示一个常见的交互场景示意：
# 查看当前主节点地址
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster# 查看 master 的状态信息
redis-cli -p 26379 SENTINEL MASTER mymaster
1.4 集群与单点的对比与适用场景
与 Redis Cluster 的分布式分区不同，Redis Sentinel 更专注于<高可用性与故障恢复，通常适用于需要快速故障切换且数据未强制水平分区的小到中型场景。单点或小规模集群在 Sentinel 架构下也能实现较低的运维成本与较快的恢复时间。
在高并发写入或对可用性要求极高的应用场景中，结合主从复制的容量拓展、以及对客户端的 sentinel 感知能力，能实现快速故障切换与最小化的业务中断。同时，对于需要跨区域部署的场景，建议增加 Sentinel 实例多样性与地理分布，以提升可用性边界。
因此，在设计阶段应权衡 数据一致性、容错能力和运维复杂度，将 Sentinel 配置与 Redis 主从结构结合，最大化系统的鲁棒性与可维护性。
2. 部署步骤
2.1 环境准备与依赖
在正式部署<强>Redis Sentinel 高可用前，需要准备多节点环境以及网络连通性，确保 Sentinel 实例之间可以互信与通信。依赖项包括操作系统、Redis 镜像或包、以及网络端口。同时，合理规划端口映射与防火墙策略，确保 26379 端口可达。
为避免单点故障，建议部署 3 到 5 个 Sentinel 实例，并将它们分布在不同的物理或虚拟机上。这样在网络分区时，仍能通过多数原则维持可用性。监控与日志记录也应同步启用，方便事后排错。
接下来将展示一个基础的 Redis 主从与 Sentinel 的部署样例，便于理解各组件的关系与配置入口。
# redis.conf（主节点）常用要点
bind 0.0.0.0
port 6379
appendonly yes
# 主从复制：此处为主节点，不包含 slaveof 指令# redis.conf（从节点）常用要点
bind 0.0.0.0
port 6379
slaveof 127.0.0.1 6379
2.2 部署 Redis 主从复制结构
需要先部署一个主节点与一个或多个从节点，确保数据写入在主节点完成后再通过复制传播到从节点。主从复制关系是 Sentinel 触发故障转移的重要前提，在 Sentinel 选出新主后，从节点会自动重定向到新主继续同步。
在部署初期，可以先手工启动主从对等，验证复制链路与延迟；随后将 Sentinel 加入，这样一旦主节点出现故障，Sentinel 能自动介入并完成故障转移。下面给出一个简化的部署片段以示范关系建立。
为确保安全性，生产环境中应为 Redis 配置认证、名称空间以及日志输出，具体可参照以下配置要点。认证策略和日志级别是稳定运行的关键。
# redis.conf（主节点）示例
bind 0.0.0.0
port 6379
requirepass yourpass
appendonly yes# redis.conf（从节点）示例
bind 0.0.0.0
port 6379
requirepass yourpass
slaveof 127.0.0.1 6379
masterauth yourpass
2.3 部署 Sentinel 实例
在部署 Sentinel 时，需为每个 Sentinel 实例准备一个单独的 sentinel.conf 配置文件，定义要监控的主节点、故障转移参数与并发策略。多实例并发工作可以显著提升故障切换的鲁棒性。
为了便于扩展和运维，建议将 Sentinel 配置做成模板，在必要时扩容或调整参数。下面给出一个典型的 sentinel.conf 配置模板片段，方便快速落地。
在实际运维中，建议结合 系统服务管理器（如 systemd） 进行守护进程管理，并通过 日志轮转 防止日志无限增长。
# sentinel.conf 示例
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster YourPass
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1
2.4 配置 sentinels 之间的通信与安全
Sentinel 节点之间需要稳定的网络连接与认证机制，确保投票与故障转移信息的传输是可信的。加密网络、访问控制和最小权限原则应作为基本策略纳入日常运维中。
可以通过在 sentinel.conf 中设置 requirepass 与 masterauth 等选项来实现基本认证，确保仅授权的 Sentinel 实例可以对被监控的 Redis 实例进行控制。
此外，监控告警也应和部署流程绑定，在出现分区或实例不可用时，及时通知运维人员进行干预。以下是一个简化的访问控制示例：
# sentinel.conf 访问控制要点
sentinel auth-pass mymaster YourPass
# 如使用 ACL，请在 Redis 6 及以上版本启用
2.5 验证高可用部署
完成部署后，应对监控、故障切换与新主配置进行全面验证。可以通过发送诊断命令来检查监控状态、主从同步情况以及故障转移触发条件是否满足。验证要点包括监控状态、从节点同步延迟、以及客户端能否正确发现新主。
一个常用的验证流程是：先将主节点下线模拟故障，然后观察 Sentinel 是否达成投票并触发故障切换，最后确认新主可对外提供服务并且从节点开始向新主同步数据。
在验证阶段，您还可以使用如下命令来查看 Sentinel 的当前状态与监控结果，确保部署符合预期。
redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL monitors
redis-cli -p 26379 SENTINEL sentinels mymaster
3. 故障切换全流程
3.1 故障检测到 master 失效
当主节点出现网络不可用、进程崩溃或超出设定的下线时间阈值时，Sentinel 将把主节点标记为潜在不可用，并对周边的 Sentinel 进行状态更新以确保信息一致性。
系统会自动触发对故障状态的传播，进而进入投票阶段。此阶段的关键在于多数哨兵的同意，以避免误判带来的服务中断。
在这一步，运维可以通过检查 SENTINEL MASTER、SENTINEL MONITORS 等命令来确认监控状态与主节点信息是否正确。
redis-cli -p 26379 SENTINEL MASTER mymaster
redis-cli -p 26379 SENTINEL MONITORS
3.2 Sentinels 达成投票、选举新主
当投票条件达到门槛时，Sentinel 会从现有副本中选择一个最合适的新主，新的主通常是最近同期数据量最大且延迟较低的从节点，并对集群中其他从节点进行重新配置。
选举过程通过网络通信完成，期间所有参与实例将更新彼此的状态并确保新主地址在整个集群中可被发现。投票结果与新主信息将被持续沿用至下一个故障轮次，从而保障系统的稳定性。
为了确保切换顺利，客户端应用需具备哨兵感知能力，能够实时获取新主地址并切换目标节点。下面是获取新主地址的一组命令示例：
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
redis-cli -p 26379 SENTINEL MASTER mymaster
3.3 新主配置副本重定向与客户端更新
新主被选出后，从节点需要重新配置为新主的地址，并开始对新主进行数据同步。与此同时，客户端连接需要通过 Sentinel 的信息进行重定向，以避免访问到旧的主节点。
在应用层，推荐使用 Sentinel 客户端或库提供的自动发现能力，以实现对新主的动态切换，降低人工干预成本与恢复时间。下方是一个 Python Sentinel 客户端的示例，展示如何获取新主并执行写入/读取：
from redis.sentinel import Sentinelsentinel = Sentinel([('127.0.0.1', 26379)], socket_timeout=0.1)
master = sentinel.master_for('mymaster', socket_timeout=0.1)
slave = sentinel.slave_for('mymaster', socket_timeout=0.1)# 写入示例
master.set('key', 'value')
# 读取示例
print(master.get('key'))
3.4 故障恢复后的环境回归与持续优化
故障切换完成后，系统应进入自愈与自检阶段，持续对新主与副本的同步状态进行监控，确保数据一致性与低延迟。针对恢复后的环境进行容量、网络与延迟的回归测试，演练多种故障场景，提升对异常的快速应对能力。
同时，日志与告警策略需回退至正常运行状态，确保后续故障再次出现时能够更快地诊断与处置。为确保长期稳定，建议定期重新评估 quorum、并发同步数和下线阈值等关键参数。
# 评估与优化要点（示例）
# 调整冗余度和故障切换速度
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 8000
sentinel parallel-syncs mymaster 2
