适用场景

数据库高可用的目标是"故障时业务能继续"，而不是"永远不宕机"。关键是切换要快、数据要一致、切换后要有人知道。

配置步骤（Redis 高可用（主从 + 哨兵 / 集群））

# 哨兵模式
sentinel monitor mymaster 10.0.10.31 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
# 集群模式
redis-cli --cluster create 10.0.10.31:6379 ... --cluster-replicas 1

关键参数与建议

  • 复制模式选择：同步/半同步（强一致，性能略降）vs 异步（性能好，可能丢数据）
  • 切换要自动化但可人工干预，切换后必须校验数据完整性
  • 读写分离要把"强一致性读"走主库（如支付后立即查询）
  • 延迟监控与告警必须有，延迟大时自动摘除从库
  • 定期做切换演练与备份恢复演练，两件事不能省

容易踩的坑

  • 哨兵节点数不足（少于 3 个），无法正确仲裁
  • 客户端未用哨兵感知地址，主从切换后连不上
  • 集群槽位分配不均，热点节点压力大

验证与巡检

redis-cli -p 26379 sentinel master mymaster
redis-cli -c -p 6379 cluster info
  • 巡检：哨兵 3 节点、切换演练通过、槽位分布均衡

小结

数据库高可用的验收标准：模拟主库故障，业务在约定时间内恢复，且数据一致性校验通过。做不到就还在"纸面高可用"。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。