Redis哨兵模式能自动故障转移，通过多哨兵投票识别故障、选举领头哨兵、选择最优从节点升级为主节点，并通知客户端更新地址，RTO约10–30秒，但存在异步复制导致的数据丢失风险，且写操作仍单点。
评估故障转移方案，关键不是看它“能不能切”，而是看“切得稳不稳、快不快、准不准”。不同集群模式在故障识别、切换决策、数据一致性、恢复时间等环节差异显著，必须结合业务容忍度来判断。
看故障检测是否可靠
一个故障转移方案是否可信，第一步是它能否准确识别故障。误判（把健康节点当故障）会引发不必要的切换，导致服务抖动；漏判（没发现真实故障）则直接失去高可用意义。
- Redis 哨兵依赖多个哨兵节点投票，通常需多数派确认才触发切换，抗网络抖动能力较强；但若哨兵自身部署不当（如全在单机或同一交换机），可能集体失联。
- MySQL Group Replication 使用 Paxos 协议做成员状态共识，节点离线由多数派自动驱逐，比传统心跳更健壮，但对网络分区敏感——一旦出现脑裂，可能分裂成两个独立主库。
- 简单主从+脚本切换方案，往往只靠 ping 或端口探测，极易因瞬时网络延迟误触发，且无法区分“实例卡死”和“网络不通”，风险较高。
看切换过程是否可控
切换不是“换主”就结束，而是包括：旧主隔离、新主提升、从库重连、客户端路由更新、连接池刷新等一系列动作。任何一环出错，都可能导致写丢失、读脏、连接失败。
- Redis Cluster 内置自动故障转移，主节点宕机后，其从节点会在约10–30秒内被选举为新主，并广播更新集群拓扑，客户端收到 MOVED/ASK 重定向后可继续操作，无需中间件介入。
- MySQL Fabric 已停止维护，而 MySQL Router + InnoDB Cluster（基于 Group Replication）能自动感知角色变更，但应用层若直连 IP，仍需配合 DNS 切换或 VIP 漂移，否则客户端会持续发请求到已下线节点。
- 自研 HA 脚本常忽略“脑裂防护”——比如未强制关闭旧主的写权限，就提升从库为主库，结果两边同时接受写入，造成数据冲突。
看数据一致性是否有保障
故障转移不是以“服务恢复”为终点，而是以“数据不丢、不错”为底线。异步复制类方案天然存在延迟，切换时若未校验同步位点，极易丢写。
- 半同步复制（如 MySQL 的 AFTER_SYNC）要求至少一个从库落盘 relay log 后主库才返回成功，大幅降低切换丢数据概率，但仍非绝对——从库落盘后崩溃未刷盘，也可能丢失。
- 强一致方案如 MySQL Group Replication 或 TiDB 的 Raft，写入需多数节点持久化才确认，故障转移后数据必然完整，但代价是写延迟上升、吞吐下降。
- Redis Cluster 默认采用异步复制，主节点宕机前未同步到从节点的命令会丢失；若业务要求 AOF fsync=always + 主从同机房部署，可将丢失窗口压缩至毫秒级。
看运维与扩展是否匹配实际
再先进的方案，如果团队不会调、不好查、难扩容，就是隐患。评估不能只看白皮书参数，要落到日常。
- Redis Cluster 节点数最少6个（3主3从），扩容需reshard迁移slot，过程需人工干预或脚本辅助，监控项多（Gossip状态、fail报告、migrating/importing标记），对DBA能力要求高。
- MySQL 主从+MHA 是中小团队常用组合：配置轻量、日志清晰、切换逻辑透明，但MHA本身无内置监控，需额外对接Zabbix/Prometheus；且不支持自动分片，扩展写能力只能靠拆库拆表。
- 云托管方案（如阿里云 PolarDB、腾讯云 TDSQL）把故障转移封装成黑盒，RTO/RPO有SLA承诺，运维压力小，但定制性弱、排障深度受限，且跨云迁移成本高。
