本文教你如何在一小时内用 1 主 2 从 3 哨兵的标准拓扑，把一台单点 Redis 升级为具备自动故障切换能力的高可用缓存集群。读完本文你会拿到三件可直接落地的产出：第一，主从与哨兵的完整配置文件模板，含端口、日志、持久化的合理默认；第二，客户端从直连主库切换到通过 Sentinel 获取主节点的代码示例与库选择建议；第三，一份手动 failover 演练 SOP，让团队对故障切换不再陌生。本文流程默认使用 Redis 7.x 与 Linux 发行版（Ubuntu 或 CentOS Stream 均可）。
一、为什么不直接上 Redis Cluster
如何选择 Redis 的高可用方案，是缓存层架构设计绕不开的问题。Redis Cluster 用分片提供横向扩展能力，但代价是部分多 key 操作（如 mget 跨槽）会变得繁琐，对应用层有一定改造成本。如果你的数据规模在单机内存范围内（一般 64 GB 以下），又希望故障切换自动化，哨兵模式（Sentinel）是更轻量的选择：保留主从复制的语义，再加一组独立进程监控主节点健康并在故障时投票选出新主。
哨兵集群至少要 3 个节点，因为 quorum（即多数派投票阈值，决定是否触发故障切换）默认是 2，少于 3 个哨兵无法对抗单点故障。建议把 3 个哨兵分布到 3 台不同物理机或 3 个可用区，避免和 Redis 主从共用同一台机器。底层主机选型可以参考云服务器选购指南。云服务器（即通过虚拟化技术从物理服务器集群中切分出的弹性计算资源）在缓存场景下要重点看内存大小与同可用区内网延迟。
二、主从节点的安装与基础配置
三台机器命名为 r1、r2、r3，r1 做主，r2 与 r3 做从，三台机器都跑一个哨兵进程。安装 Redis 后，主节点的 redis.conf 关键项：
- bind 0.0.0.0 与 protected-mode no：允许其他节点接入，生产环境务必配合防火墙限制
- requirepass “复杂密码”：开启密码认证
- masterauth “复杂密码”：从节点回连主节点时用同样的密码
- appendonly yes 与 appendfsync everysec：开启 AOF 持久化
- maxmemory 与 maxmemory-policy allkeys-lru：避免内存写满后阻塞
从节点在主节点配置基础上追加一行 replicaof 10.0.0.11 6379，启动后即从主节点同步全量数据。VPS（Virtual Private Server，虚拟专用服务器，通过虚拟化划分的独立实例）部署 Redis 主从时，要确认带宽（即网络出口的数据传输速率，单位 Mbps）能覆盖初始全量同步流量，否则同步会反复中断重传。具体部署流程对照美国 VPS 部署教程即可。
三、Sentinel 配置与启动
每台机器再起一个 sentinel 进程，监听 26379 端口，sentinel.conf 的核心参数：
- port 26379：哨兵监听端口
- sentinel monitor mymaster 10.0.0.11 6379 2：监控主节点，quorum 设 2
- sentinel down-after-milliseconds mymaster 5000：5 秒无响应判定为主观下线
- sentinel failover-timeout mymaster 60000：故障切换最长 60 秒
- sentinel auth-pass mymaster “复杂密码”：哨兵连接主从的密码
- sentinel parallel-syncs mymaster 1：故障切换后，每次只让 1 个从同步新主，避免击穿
三台机器分别用 redis-sentinel /etc/redis/sentinel.conf 启动哨兵进程。启动完成后用 redis-cli -p 26379 sentinel masters 查询，应能看到 mymaster 的当前主节点 IP 与从节点列表。客户端不要再写死主库 IP，应改成连接哨兵集群、由哨兵返回当前主节点 IP，主流语言的 Redis 客户端（jedis、lettuce、redis-py、go-redis）都原生支持 Sentinel 模式。
四、故障切换演练与日常巡检
部署完不要直接交给业务，先做一次手动 failover 演练，验证整个链路。建议演练步骤：
- 在主节点执行 redis-cli debug sleep 30 阻塞主节点 30 秒
- 观察哨兵日志，等待 +odown 与 +failover-state-select-slave 事件
- 从节点之一被提升为新主，确认 INFO replication 输出 role:master
- 重启原主节点，确认它自动变成从节点并追上数据
- 应用层连接主库写入，确认请求落到新主
日常巡检关注四个指标：sentinel sentinels mymaster 返回的哨兵数量是否等于 3、主从延迟（master_repl_offset 与 slave_repl_offset 的差）、used_memory_rss 增长趋势、AOF 文件大小。建议你今天就在测试环境部署一套 1 主 2 从 3 哨兵，做一次 failover 演练，再把 SOP 写进运维 wiki。可以考虑结合WordPress 性能调优实战里的对象缓存策略，把 WordPress 的 wp_options 与 transient 全部托管到这套 Redis 上，从而把数据库的重复读流量再压下去 40%。后续可以参考WordPress 香港主机购买指南对中文站点选型。总结来说，Redis 哨兵的部署门槛远低于 Cluster，只要把哨兵数量与 quorum 配置正确，再加一次完整的故障演练，就能让缓存层从单点单实例进入真正可用的高可用形态。在团队推进时，建议把本文流程沉淀为一份内部 wiki 页面，新人入职第一周就完成一次完整演练，把每一步的执行命令、预期输出、异常处理都写清楚。线上变更前再过一遍前置检查清单，确认备份、回滚脚本、灰度窗口三件事都准备就绪，再开始动作。技术细节之外，运维节奏的稳定才是长期收益的来源，定期的复盘会议、变更通报、故障演练三件事缺一不可，让团队对系统的掌控感从被动等告警切换到主动看趋势。日常巡检与季度演练应该写进岗位职责，由专人负责并对结果负责，避免责任分散导致问题被反复忽略。从更长的时间维度看，数据库优化的复利效应来自三层：架构层选对存储引擎与拓扑，配置层把硬件资源用足，应用层把 SQL 与索引写正确。三层缺一不可，团队应当让每一层都有专人持续打磨，避免只押宝硬件升级。年度做一次容量评估、季度做一次读写画像、月度做一次慢查询治理，把节奏稳定下来，业务增长才不会一次次撞到数据库的天花板。建议你今天就把本文流程在测试环境完整跑一遍，可以考虑把每一步的命令与预期输出沉淀进运维 wiki，再推荐团队按季度做一次复盘演练，让这套优化方法在团队里形成可持续的习惯。