1. 架构原理与关键组件
1.1 核心组件：主节点、从节点、哨兵
在 Redis Sentinel 高可用配置中，主节点（master）负责写入和强一致性的数据更新，从节点（slave）用作读负载分担和备份。哨兵（Sentinel）则承担监控、通知和故障转移决策，三者构成一套完整的高可用体系。
Sentinel 的核心职责是持续监控主从状态，一旦发现主节点不可用，自动触发故障转移流程，确保业务尽量不中断地继续运行。主从复制的存在，是实现数据冗余与快速切换的基础，通过复制链接和延迟来实现从节点的快速接管。
在实际部署中，主从复制是数据冗余的基础，复制延迟会影响故障转移后的数据一致性窗口，因此需要通过参数如 replica-read-only 与 min-replicas_to_write 进行协调，以确保在写入时对主节点的正确性约束。
1.2 Sentinel 的工作流程与故障转移
Sentinel 的工作流程包含监控、判定、选举和配置传播，其中监控阶段持续对 master 的状态进行评估，判断达到宕机阈值后进入判定阶段。
在选举阶段，具备多数选票的从节点成为新的主节点，原主节点在恢复后以从节点的身份加入集群。故障转移完成后，客户端需要更新连接信息，避免访问到故障节点，以保持业务可用性。
为了保障一致性，Sentinel 会将新主的 IP/端口广播给系统中的所有应用与代理，并确保数据写入仍走到正确的主节点。持续运行的监控与告警则是持续可用性的关键。
2. 落地部署的最佳实践
2.1 节点拓扑与部署方式
在实际落地中，推荐部署至少 3 个 Sentinel 实例形成法定多数，以抵抗网络分区带来的影响。Master 与从节点的数量应按照读写分离和容量进行均衡，确保在高并发场景下仍能提供稳定的访问路径。
部署地理分布对系统可靠性有显著提升，跨数据中心的 Sentinel 组合可以降低单点故障风险，但需要处理网络延迟带来的影响，避免过于频繁的切换导致读写抖动。
对于高可用的生产环境，使用容器化或虚拟化环境有利于快速弹性扩缩，并配合 服务发现 与 自动化部署管道，提升可靠性与运维效率。
2.2 配置要点与风险
在配置 Sentinel 时，设定合适的 quorum（法定票数）是关键，通常为总从节点数的一半以上。低 quorum 容易出现误判，高 quorum 则可能延迟故障转移，需要在可用性与一致性之间平衡。
为避免凭据暴露与滥用，为从节点设置独立的权限、认证密码，并在 sentinel.conf 使用 bind、protected-mode、requirepass 等参数进行保护，降低被动攻击的风险。
应对网络分区，通过告警与人工干预结合的策略，确保在极端情况下不会进行错误的主从切换。测试用例与演练脚本也是必不可少的环节，帮助团队熟悉故障处理流程。
# sentinel.conf 示例
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster mypassword
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
3. 性能优化与容量规划
3.1 连接与缓存策略
针对高并发场景，客户端连接池和异步请求模式可以显著降低延迟，确保连接在主从之间无缝重定向，避免因为短时阻塞而堆积请求。
为避免缓存雪崩，对热点数据设置合理的过期时间与预热策略，并用 哨兵+主从分离提高读取吞吐，确保鲁棒性与可扩展性。
在设计缓存策略时，将热数据优先放在能快速访问的节点，并通过读写分离将读流量分散到从节点，达到稳定的并发性能。
# redis.conf 示例
maxmemory 4gb
maxmemory-policy allkeys-lru
3.2 内存管理与数据结构选型
数据结构的选择直接影响内存占用，尽量使用简单字符串和哈希结构的高效编码，避免复杂对象。定制的 Redis 数据模型谨慎设计，减少重复数据以降低内存压力。
在持久化方面，使用持久化与日志的权衡策略，通常倾向于 AOF+RDB 的组合，并配合 定期重写，以降低日志增长带来的磁盘压力与恢复时间。
结合 Sentinel，确保在故障转移后从节点能够快速同步新主，以维持低写入延迟。复制带宽与网络延迟是关键影响因素，应通过网络优化和合理副本分布来降低其影响。
# redis.conf 示例
maxmemory 2gb
maxmemory-policy allkeys-lru
appendonly yes
appendfilename "appendonly.aof"
3.3 监控、告警与容量评估
监控是性能优化的重要手段，覆盖 Redis 与 Sentinel 的关键指标，如 复制偏移、命中率、延迟、故障检测时间等，确保问题能在早期被发现。
使用集中化的日志与时序数据分析，设定阈值与告警策略，在容量逼近时及时干预。容量规划应包含主从结构的扩缩和数据增长预测，以避免临界点上线后系统突然不可用。
# 常见监控命令示例
redis-cli INFO replication
redis-cli INFO memory
redis-cli -p 26379 INFO Sentinel
4. 实战配置示例
4.1 Redis 主配置示例
下面给出一个简化的 Redis 主节点配置，核心参数包括端口、绑定、保护模式、持久化策略，用于确保数据在高可用场景下的一致性与可恢复性。
配置中的持久化策略需要与故障转移策略协同，否则在主节点故障时新主的日志会出现时序问题。注意配置中的 save、appendonly、appendfilename，确保在不同故障场景下数据能够正确恢复。
# redis.conf 示例（主节点）
bind 0.0.0.0
protected-mode yes
port 6379
dir /var/lib/redis
dbfilename dump.rdb
appendonly yes
appendfilename "appendonly.aof"
save 900 1
save 300 10
save 60 10000
4.2 Sentinel 配置示例
下面是一个典型的 Sentinel 配置片段，定义了监控对象、投票阈值、故障检测时间，并指出了从节点的选择逻辑。
在实际环境中，应该部署多实例 Sentinel，以形成多数派，确保在网络分区时仍能正确进行主节点选举并切换。
# sentinel.conf 示例
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster yourpassword
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
5. 故障处理与测试
5.1 故障场景演练
常见的故障场景包括主节点宕机、网络分区、从节点落后等，通过演练可以验证 Sentinel 的响应与自动化故障转移的正确性，确保系统在真实故障时仍能保持可用性。
演练过程中应记录关键指标，如故障检测时间、故障转移完成时间、以及重新配置的耗时，以便后续优化。多场景覆盖有助于降低上线风险。
5.2 演练脚本与回放
提供一个简洁的演练脚本，用于模拟主节点不可用并触发故障转移，验证网络和客户端切换逻辑，确保从节点能够接替成为新主。
在回放阶段，还需要对比实际的故障时序与预期时序，
# simple failover test (伪代码/示例)
# 1. 停止主节点
redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN NOSAVE
# 2. Sentinel 触发故障转移后查看状态
redis-cli -p 26379 INFO Sentinel
# 3. 验证新主是否对外提供写入
redis-cli -h 127.0.0.1 -p 6379 PING
