1. Redis Sentinel 高可用架构全景
1. 架构要点
在高可用场景中，Sentinel 负责监控 Redis 主从实例的健康，并在检测到主节点不可用时发起故障转移。它通过 多节点投票机制来选取新的主节点，确保集群的持续可用性。
每个 Sentinel 实例都维护着一个关于主从关系的状态视图，实时与配置中心协同，以降低单点故障风险。
核心目标包括：无缝切换、数据一致性、可观测性与运维自动化。需要注意的是，Sentinel 自身不是数据存储的集群，而是控制平面的高可用组件，依赖于 Redis 的主从复制来保证数据可用性。
2. 部署拓扑与冗余
一个常见的高可用拓扑是：3 台 Sentinel + 2 台 Redis 实例（1 主 + 1 备），分布在不同的物理或网络域，以避免单点故障。通过至少 3 台哨兵来实现多数表决，故障转移才具有高可用性保障。
在多域部署中，确保 Sentinel 之间的网络延迟可控，时钟同步和一致性校验是成功故障转移的前提。建议对哨兵端口和 Redis 端口进行分离，提升可维护性和安全性。
2. 部署环境与依赖
1. 版本与依赖
推荐使用稳定版本的 Redis（如 Redis 6.x/7.x）并搭配对应版本的 Redis‑Sentinel。版本匹配与二进制兼容性是确保功能完整性的关键因素。TLS/加密传输在新版里逐步完善，若对安全有高要求，需结合网络层加密方案。
在生产中，务必开启时钟同步（NTP/Chrony）以及合理的 资源配额，确保 Sentinel 的监控轮询和故障投票不被系统抖动干扰。
2. 系统配置与服务管理
为 Redis 与 Sentinel 设定独立的系统用户和数据目录，确保权限分离，减少潜在风险。系统资源限制、ulimits、文件描述符等配置也需事先对应调整，以支撑高并发与多实例并存。
以下给出常用的系统服务配置片段，可直接用于 systemd 场景。安全性优先、最小权限原则应贯穿实现。
# /etc/systemd/system/redis-master.service
[Unit]
Description=Redis Master
After=network-online.target[Service]
User=redis
Group=redis
ExecStart=/usr/bin/redis-server /etc/redis/redis-master.conf
Restart=always[Install]
WantedBy=multi-user.target
另外是 sentinel 的系统服务布局示例。
# /etc/systemd/system/redis-sentinel.service
[Unit]
Description=Redis Sentinel
After=network-online.target[Service]
User=redis
Group=redis
ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf
Restart=always[Install]
WantedBy=multi-user.target
3. 核心配置要点与示例
1. redis.conf 的关键选项
在 Redis 的 master/replica 配置中，确保开启持久化、授权访问和合理的内存策略。appendonly enabled、requirepass、masterauth 是常见的安全与可用性控制点。
同时，保护模式、bind 与端口绑定策略、以及 复制相关参数（如 replica-serve-stale-data）影响故障转移过程中的数据可用性。
# redis-master.conf
bind 0.0.0.0
port 6379
protected-mode no
requirepass RedisStrongPass!
masterauth RedisStrongPass!
appendonly yes
save 900 1
save 300 10
dir /var/lib/redis
loglevel warning
2. sentinel.conf 的关键选项
Sentinel 的最核心是对主从关系的监控与故障转移的控制参数。监控目标、超时阈值与并发策略将直接决定切换的时效性与稳定性。
典型配置包括：监控主节点、下线时间、故障超时、并发同步数等。以下给出一个简化示例，便于理解与落地。
# sentinel.conf
port 26379
bind 0.0.0.0
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel auth-pass mymaster RedisStrongPass!
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
4. 故障转移实战流程
1. 故障检测与投票机制
当主节点不可用时，哨兵通过心跳/健康检测判定，随后对候选主进行投票。多数派原则确保新主具备可用性与数据实时性。
在此阶段，备用从节点会准备提升为主并重新与新主建立复制关系，确保数据可用性与一致性。 Sentinel 的日志与通知对后续排错十分关键。
2. 自动故障转移执行
故障转移通常含有以下步骤：将选举出的新主标记并通知其余从节点，重新指派从节点以保持副本数；通过 切换命令完成从主到从的角色切换；最后，应用层需要更新连接字符串以指向新主。最小化客户端连接中断是设计要点之一。
# 模拟故障转移后，手动校验的简易步骤
redis-cli -p 6379 INFO replication
redis-cli -p 26379 SENTINEL masters
5. 监控、安全与运维要点
1. 监控要点
关键监控指标包括：sentinel 状态、主从拓扑、故障投票数、下线时间、故障转移耗时等。将这些指标接入现有监控平台，结合告警策略，能快速定位瓶颈和异常。
日志统一收集与结构化告警能够提升运维效率。告警阈值与滚动窗口是可靠的告警策略基石。
2. 安全性与访问控制
使用 AUTH、masterauth、以及网络层访问控制组合来保护数据与控制通道。避免暴露 Sentinel 的管理端口在公网，优先采用内网通信与加密传输。可选的 TLS/证书机制进一步提升安全性。
# 典型的认证配置片段
requirepass VerySecurePass!
# sentinel 使用 masterauth 保护主从通信
6. 自动化与运维最佳实践
1. 配置版本化与回滚
将 redis.conf、sentinel.conf、以及系统服务配置纳入版本化管理，变更审计、回滚策略成为日常运维的一部分。
通过基础设施即代码工具（如 Ansible、Terraform）实现一致性部署，多环境一致性是提升稳定性的关键。
2. 演练与容量规划
定期演练故障转移，模拟不同故障场景，帮助团队熟悉应急流程并发现潜在瓶颈。结合数据增长趋势进行容量规划，确保 哨兵数量、主从数量、网络带宽等资源充足。
# 演练脚本示例（简化版）
#!/usr/bin/env bash
# 假设使用的是 sentinel 进行故障转移演练
redis-cli -p 6379 PING
redis-cli -p 26379 SENTINEL masters
