适用范围与设计目标
本文作为「Redis Sentinel 高可用」场景的架构参考，适用于非分片 Redis 主从复制与 Sentinel。先明确业务能容忍的写入中断、数据丢失、读一致性和跨故障域成本；这些目标需要环境测试，不能从组件名称推导出来。若系统采用 Redis Cluster，应使用其集群发现与故障转移机制另行设计。
区分故障判断与切换授权
quorum 决定多少 Sentinel 共同判断主节点不可达；真正发起自动故障转移还需要满足多数 Sentinel 的授权要求。降低 quorum 不能让失去多数的分区继续自动切换。官方建议稳健部署至少使用三个 Sentinel，并置于能独立故障的机器或故障域，具体依据见文末 Sentinel 文档。
设计时列出机器、机架、网络和可用区失效后的剩余成员及连通性。三进程集中在同一宿主机不提供三个独立故障视角；只有两个故障域时，还需要明确整域失效对投票和数据副本的影响。
分开核对三条连接路径
- Sentinel 之间需要交换监控与选举信息。
- Sentinel 需要连接所有可能承担主从角色的 Redis 实例。
- 应用需要连接多个 Sentinel，并能访问它们返回的 Redis 地址。
把每条路径的认证、TLS、名称解析和网络策略写入接入清单。容器或 NAT 场景特别核对通告地址，不能只验证宿主机上能够连接。为 Sentinel 的状态配置文件保留正确写权限及持久化位置，避免重启后依赖过期配置。
客户端必须支持重新发现
应用配置应包含一组 Sentinel 地址与一致的主组名，而非把当前主节点 IP 固定为长期写入口。客户端向 Sentinel 查询主地址后，还需按客户端规范验证角色；重连时重新发现，并替换连接池中的旧连接。Sentinel 不代理业务命令，认证和超时也要分别处理。
以下查询只用于核对发现结果。大写字符串是主机与主组名占位符，认证参数按环境的安全凭据方式补充：
redis-cli -h REPLACE_WITH_SENTINEL_HOST -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME REPLACE_WITH_MASTER_NAME
redis-cli -h REPLACE_WITH_REDIS_HOST -p 6379 ROLE把数据语义写进应用约定
异步复制下，已确认写入仍可能在故障转移中丢失。断连后的命令也可能处于「服务端已执行、客户端未收到响应」状态，重试策略应结合操作幂等性和业务去重。不要把自动重连等同于业务安全重试。
设计评审应明确关键数据能否重建、如何核对重复操作、是否允许副本读及如何识别过期数据。持久化、备份与 Sentinel 各有作用，需要分别制定恢复验证，而不是互相替代。
验收与停止条件
在测试环境覆盖主节点失效、单个 Sentinel 失效、网络隔离及旧主恢复，记录发现收敛、连接池恢复和业务请求结果。验收标准包括所有应用获得一致的新主、旧主不继续承接有效写入、数据偏差符合事先目标。若发现返回地址不可达、客户端仍固定连旧主或多数故障域设计不成立，应停止上线并修正架构；上线前保留原连接配置和数据恢复方案。