1. 方案选型与整体设计思路先说结论如果你正在维护一个流量不大不小、对数据一致性要求较高、又不想直接上Cluster模式集群模式的业务系统那么主从复制 哨兵Sentinel这套组合基本就是性价比最高的高可用方案了。我在实际项目里见过不少朋友一上来就奔着Redis Cluster去结果发现槽位分配、多键操作限制、客户端升级这些连带改动一大堆反而把自己搞得很痛苦。其实在很多场景下主从加哨兵已经能解决90%的高可用问题——主库挂了自动切换从库分担读压力数据有冗余备份配置和维护成本都远低于Cluster。这里先把这个方案的核心逻辑讲清楚后面再一步步带你搭起来。1.1 为什么是主从哨兵而不是其他方案先看几张常见架构的对比方案数据冗余故障自动切换读写分离扩展性配置复杂度单机Redis无无无无最低主从复制有无需手动支持弱低主从哨兵有有支持弱中Redis Cluster有有支持强高单机Redis自不必说宕机直接全盘不可用。纯主从复制虽然有了数据冗余但主库故障时从库不会自动上位你得半夜爬起来手动执行命令切换这中间的业务中断时间完全不可控。而Cluster模式虽然扩展性最强但它引入了数据分片的概念槽位slot分布在多个节点上多键操作受到限制很多已有业务代码需要改造。主从哨兵这套方案本质上是在主从复制的基础上增加了一层监督者。哨兵节点负责监控所有Redis节点的健康状态当主节点出现故障时哨兵集群通过投票机制选举出新的主节点并自动把其他从节点的主库指向切换过去。整个过程不需要人工干预业务方只需要连接哨兵节点获取当前主库地址即可。1.2 这套方案适合什么业务场景根据我的经验这几类场景特别适合主从哨兵第一类是读多写少的业务。比如内容管理系统、商品详情页缓存、配置中心等读请求远多于写请求。通过主从复制可以把读流量分散到多个从库上主库只负责写Redis的QPS能翻好几倍。第二类是数据量可控但要求高可用的业务。比如用户会话信息、订单状态缓存、实时排行榜等这些数据量通常在几GB到几十GB之间单机内存够用不需要分片但宕机几分钟都是不可接受的。第三类是已有单机Redis想平滑升级的业务。从一个节点升级成主从哨兵不需要改动业务代码客户端连接方式从直连Redis改为连接哨兵服务或者使用支持哨兵的客户端连接池即可迁移成本很低。如果你已经确定这套方案适合你那就可以开始动手了。后面我以一个三节点环境为例完整演示从零到一搭建主从复制和哨兵集群的全过程包含每一步的配置文件、命令、验证方法和踩坑记录。2. 主从复制搭建全流程主从复制是整个高可用方案的基础哨兵只是在主从基础上做自动故障转移。所以先把主从复制搭好搭的过程中理解它的工作原理后面配置哨兵就会很顺。2.1 环境准备与Redis安装这里我用三台Linux服务器为例分别称为节点A、节点B、节点C。实际生产环境中节点最好分布在不同机架或不同可用区避免物理层面的单点故障。测试环境用一台机器开三个实例也可以但生产环境强烈建议物理隔离。先确认系统版本和依赖cat /etc/os-release # 以 CentOS 7/8 或 Ubuntu 18.04/20.04 为例 # 安装基础依赖 yum install -y gcc gcc-c make tcl # CentOS # apt-get install -y build-essential tcl # UbuntuRedis的安装我推荐用源码编译安装虽然比包管理器多几步但好处是版本可控、参数可定制。这里用 Redis 6.x 版本演示稳定性和功能都经过了生产环境验证。# 下载源码包在 /usr/local/src 下操作 cd /usr/local/src wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar xzf redis-6.2.14.tar.gz cd redis-6.2.14 # 编译安装 make -j4 make install PREFIX/usr/local/redis # 添加环境变量 echo export PATH/usr/local/redis/bin:$PATH /etc/profile source /etc/profile装完后先验证一下redis-server -v # Redis server v6.2.14 sha00000000:0 malloclibc bits64 buildxxx三个节点都重复上述操作把Redis基础环境准备好。在生产环境里我一般还会顺手做个systemd服务脚本方便开机自启和统一管理后面如果你需要也可以加上。2.2 主节点配置详解进入Redis安装目录下的配置文件目录开始配置主节点。核心配置项如下# 在 /usr/local/redis/etc/redis.conf 中修改 # 绑定地址生产环境根据实际内网IP修改 bind 0.0.0.0 # 端口号保持默认或自定义生产环境建议别用默认6379避免被扫描 port 6379 # 守护进程模式 daemonize yes # PID文件和日志文件位置 pidfile /var/run/redis_6379.pid logfile /var/log/redis_6379.log # 数据持久化主从场景建议AOF和RDB同时开启 appendonly yes appendfilename appendonly.aof appendfsync everysec # 设置密码生产环境强烈建议 requirepass your_redis_password # 如果不设置密码至少要做内网访问控制 protected-mode yes这里重点说几个容易被忽视的配置项daemonize yes是把Redis放到后台运行否则你一关终端Redis就跟着停了。appendonly yes是开启AOF持久化主从复制场景下从节点的数据最终来自主节点的持久化文件主节点如果持久化没做好崩溃恢复后数据本身就是旧的复制给从库也是错的。requirepass用于设置认证密码主从复制时从库要用这个密码连接主库哨兵也要用它来访问Redis实例。配置好后启动主节点/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf验证是否启动成功redis-cli -a your_redis_password ping # PONG2.3 从节点配置与主从关系建立从节点的配置和主节点基本相同但有几个关键差异点。以节点B为例# 修改 /usr/local/redis/etc/redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /var/run/redis_6379.pid logfile /var/log/redis_6379.log appendonly yes appendfilename appendonly.aof appendfsync everysec requirepass your_redis_password # 关键指定主节点地址和端口 replicaof 192.168.1.10 6379 # 主节点设置了密码这里要配上 masterauth your_redis_password在Redis 5.0之前的版本中这个参数叫slaveof从Redis 5.0开始官方建议使用replicaof语义更准确。如果你的业务代码里有通过SLAVEOF命令动态切换主库的脚本注意在新版本中对应的是REPLICAOF命令。这里也可以不修改配置文件通过命令行动态设置从主关系但不推荐因为重启服务器之后会丢失redis-cli -a your_redis_password replicaof 192.168.1.10 6379配置好后启动从节点B/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf然后分别在三个节点上检查复制状态# 在主节点A上查看从库信息 redis-cli -a your_redis_password info replication在主节点上预期看到类似这样的输出# Replication role:master connected_slaves:1 slave0:ip192.168.1.11,port6379,stateonline,offset1556,lag0stateonline表示从节点已经是在线同步状态offset是已经同步的字节偏移量。在从节点B上执行同样命令预期输出会是role:slave master_host:192.168.1.10 master_port:6379 master_link_status:up slave_read_only:1 offset:1556看到master_link_status:up就说明主从链路已经建立数据正在同步。slave_read_only:1表示从节点默认只读这个默认配置很重要防止脏数据写入从库造成主从数据不一致。2.4 主从复制的核心机制与参数调优主从复制底层机制很多人搞不清楚其实整个流程可以拆成三个阶段理解了它你排查问题会快很多。第一阶段是建立连接和握手。从节点向主节点发送PSYNC命令传递自己的复制ID和偏移量。如果是第一次复制复制ID未知主节点会触发全量复制。第二阶段是全量复制。主节点执行BGSAVE生成RDB快照文件同时用缓冲区记录后续的写命令。RDB文件生成后通过网络发给从节点从节点清空旧数据加载RDB文件。同步完成后主节点把缓冲区的写命令继续发给从节点。第三阶段是增量同步。主节点把每一次写命令通过传输协议实时转发给从节点从节点执行相同的命令最终达到数据一致。整个过程基于偏移量offset来对齐从节点每执行一条命令都会更新自己的offset并在心跳中回报给主节点。全量复制会遇到一个经典的生产问题如果从节点和主节点的数据差距很大RDB文件传输又慢缓冲区设置不合理就可能导致同步循环或者数据一直追不上。关键的调优参数有三个# 主节点上设置复制缓冲区大小 repl-backlog-size 128mb # 从节点上设置全量复制超时时间 repl-timeout 120 # 从节点向主节点发送心跳的间隔 repl-ping-replica-period 10repl-backlog-size是主节点用来保存写命令的环形缓冲区。如果网络抖动导致从节点短暂断连靠这个缓冲区可以实现增量续传而不是重新全量复制。这个值设得太小断线时间稍长就得重新全量同步代价很大。我曾见过有人默认1MB没改主库一写多就从库掉线重连反复全量复制把主库IO打满。建议至少128MB起步如果单节点写命令多直接上256MB。repl-timeout是从节点判断主节点是否超时的依据如果60秒内没有收到主节点的心跳或数据从节点会判定连接超时。在网络环境复杂的场景适当调大这个值可以减少误判。但注意它和哨兵的down-after-milliseconds是独立的后面会讲到。repl-ping-replica-period控制从节点向主节点发送心跳的间隔默认10秒。在主从链路稳定的情况下一般不用改。但如果你的网络设备对空闲连接有自动回收策略可以稍微调小到5秒避免长连接被中间设备断开后要等很久才被发现。2.5 读写分离与从节点只读保护主从复制建好后很自然的一个用法就是读写分离。写操作走主节点读操作走从节点。一个容易被忽略的细节是从节点默认开启了只读模式slave-read-only yes这是一个非常安全的设计。但如果你用管理账号对从节点执行了写操作Redis 6.x虽然会拒绝但如果你通过某些客户端工具配置了错误的主从地址写请求被路由到了从节点只读模式的保护就很重要了。如果在从节点上强制写入会报这样的错误(error) READONLY You cant write against a read only replica.另外从节点在处理读请求时由于主从之间存在同步延迟可能会有短暂的数据不一致。解决这个问题的思路有两种一种是在业务代码中识别强实时性数据全部走主库读另一种是使用WAIT命令确认从节点已经同步到指定偏移量再读。后者性能损耗比较大一般只在金融类交易场景中使用。到这里一个基础的主从复制集群已经搭建完成。但说实话到了这一步还远没有达到高可用——主节点宕机了从节点虽然数据还在但不会自动上位业务写入全部会失败。这就是为什么还需要哨兵。3. 哨兵模式部署与故障转移哨兵Sentinel在Redis高可用架构里充当的是监督者决策者的角色。它的职责可以概括为三件事监控、通知、自动故障转移。哨兵本身也是Redis服务器只不过它运行在特殊模式下不存储业务数据而是专门负责监控其他Redis实例的健康状态。生产环境至少部署3个哨兵节点形成一个哨兵集群这样既避免单点故障又能在主节点宕机时通过投票机制达成一致选出新的主节点。3.1 哨兵的三种角色与工作模式哨兵集群内部有几类角色哨兵节点Sentinel监控Redis主从节点以及监控其他哨兵节点。主节点Master提供写服务的Redis实例。从节点Replica提供读服务的Redis实例。哨兵之间通过发布/订阅频道通信它们会周期性地向所有被监控的Redis节点发送命令检查对方是否正常响应。当某个哨兵发现主节点无法响应时它不会立刻宣布主节点下线——毕竟网络抖动可能导致误判它首先要征求其他哨兵的意见。这里有两个关键概念主观下线Subjectively DownSDOWN单个哨兵认为主节点下线了。客观下线Objectively DownODOWN达到指定数量quorum的哨兵都认为主节点下线了。当一个主节点被判断为客观下线后哨兵集群就开始执行故障转移从现有的从节点中根据一定规则选出一个新的主节点然后通知所有其他从节点将新主节点设为它们的主库。3.2 哨兵配置文件详解以节点A为例创建一个独立的哨兵配置文件。哨兵配置文件的路径和Redis配置文件分开内容也要单独写vim /usr/local/redis/etc/sentinel.conf核心配置项如下# 哨兵监听端口 port 26379 # 守护进程模式 daemonize yes # 日志文件 logfile /var/log/redis_sentinel.log # 监控的主节点名称、IP、端口、投票法定数 sentinel monitor mymaster 192.168.1.10 6379 2 # 主节点密码 sentinel auth-pass mymaster your_redis_password # 主节点判定下线的超时时间毫秒 sentinel down-after-milliseconds mymaster 5000 # 故障转移超时时间毫秒 sentinel failover-timeout mymaster 15000 # 故障转移后同时向新主节点发起同步的从节点数量 sentinel parallel-syncs mymaster 1逐项解释一下sentinel monitor mymaster 192.168.1.10 6379 2是哨兵配置里最核心的一行。mymaster是这个主节点组在哨兵配置中的逻辑名称你可以随意命名但要保证三个哨兵配置里的一致性2是 quorum意思是至少需要2个哨兵同意才能判定主节点客观下线。quorum 的取值需要根据哨兵总数来定总共3个哨兵quorum设为2总共5个哨兵quorum设为3。它的含义是达成一致意见的最少哨兵数量取值为哨兵总数的一半以上即可。sentinel down-after-milliseconds是哨兵判断某个节点是否下线的超时时间。5000毫秒意味着一个哨兵如果在5秒内无法与主节点正常通信就会给该节点标记为主观下线。这个值不宜设得太小否则网络抖动就会频繁触发故障转移也不宜设得太大否则故障恢复时间太长。我在生产环境一般设为10秒左右。sentinel parallel-syncs控制故障转移后最多有多少个从节点可以同时向新主节点发起同步。设置为1意味着逐个同步避免多个从节点同时全量复制把新主节点的带宽和IO打爆。sentinel failover-timeout是故障转移的超时时间包括检测到主节点客观下线、选举新主节点、通知所有从节点切换主库的整个过程。设置太短可能导致同步未完成就触发新的选举设置太长则会导致恢复时间变长。三个节点都需要配置这份哨兵文件唯一不同的可能是sentinel monitor行里的地址要统一指向最初的主节点地址。注意即使和哨兵部署在同一台机器上哨兵配置和Redis实例配置也要分开文件管理。启动哨兵/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf启动后验证哨兵状态redis-cli -p 26379 sentinel master mymaster # 输出结果中包含主节点的地址、端口、状态等信息 redis-cli -p 26379 sentinel replicas mymaster # 显示被监控的从节点列表 redis-cli -p 26379 sentinel sentinels mymaster # 显示其他哨兵节点的信息当看到主节点状态为sdown或odown之外的正常状态并且从节点信息正常显示时哨兵集群就算部署成功了。3.3 故障转移的完整流程拆解理解故障转移的执行过程对排查问题会很有帮助。整个过程可以拆成几个步骤第一步哨兵节点通过心跳检测发现主节点异常。每个哨兵每秒向主节点发送一次PING命令如果在down-after-milliseconds指定的时间内没有得到有效回复该哨兵会标记主节点为主观下线SDOWN。第二步主观下线的哨兵会通过发布/订阅频道向其他哨兵广播这一消息并请求其他哨兵确认。其他哨兵在收到请求后也会检查自己与主节点的连接状态。当同意主节点下线的哨兵数量达到quorum阈值时该主节点被标记为客观下线ODOWN。这一步有个容易误判的情况主节点所在服务器负载极高导致Redis进程无法及时响应PING但进程其实没有崩溃。此时如果没有合理的超时设置可能会触发无意义的故障转移。所以我才建议在生产环境把down-after-milliseconds设置在5到10秒之间太灵敏反而是灾难。第三步确认客观下线后哨兵集群开始选举领导者。这个选举过程用的是Raft算法类似的思想每个哨兵都有投票权拥有从节点投票数最多的哨兵将成为执行故障转移的领导者。多个哨兵之间通过消息交互达成共识保证了同一时刻只有一个哨兵在执行故障转移避免两个哨兵同时把不同的从节点提升为主节点。第四步领导者哨兵从当前所有健康的从节点中选出一个新的主节点。选择规则优先级如下优先级判断条件1从节点的复制偏移量是否最新数据最完整2从节点的优先级配置文件中的replica-priority数值越小越优先3从节点的运行IDRun ID越小越优先简单来说优先选择数据最完整的从节点如果数据完整度相同选配置优先级最高的如果还相同就选运行ID最小的。这里的replica-priority可以在从节点配置文件里设置你可以把某些硬件更好的从节点的优先级调低比如设成50让它在选举中更占优势。第五步新主节点确定后哨兵会向它发送SLAVEOF NO ONE命令让它脱离主从关系成为新的主节点并将旧主节点的配置覆盖掉。第六步哨兵向其他所有从节点发送SLAVEOF 新主节点IP 新主节点端口命令让它们重新指向新主节点开始同步新主节点的数据。第七步旧主节点如果恢复了哨兵也会将其配置为从节点指向新主节点保证整个集群的收敛。3.4 Sentinel与Redis实例的连接机制哨兵除了要监控Redis实例还要能和Redis实例进行认证和数据交互。如果你的Redis设置了密码必须注意哨兵配置的两个认证点第一个是前面的sentinel auth-pass mymaster your_redis_password这是哨兵连接主节点和从节点的密码。每台被监控的Redis节点密码都需要保持一致否则哨兵无法完成监控。第二个是哨兵节点之间的通信。哨兵之间通过sentinel协议而不是普通Redis客户端协议通信因此哨兵之间的连接不依赖于requirepass。但如果哨兵配置文件里也设置了requirepass哨兵间就要用sentinel auth-pass来加密码一般不推荐这么做会增加故障转移期间的复杂度。另外要注意如果你的主从节点设置了不同的密码或者某个从节点单独设置了另一个密码哨兵配置里要分别指定。哨兵识别从节点的时候会对每个从节点单独发起认证认证失败则该从节点不会被纳入故障转移候选列表。3.5 手动验证故障转移效果搭建完成后一定要手动做一次故障演练验证哨兵能不能自动完成主从切换。我在生产环境每次变更后都会做一次确保不是纸上谈兵。模拟主节点宕机# 在节点A上直接杀掉Redis主进程 kill -9 $(cat /var/run/redis_6379.pid)然后等待5秒down-after-milliseconds再观察哨兵日志tail -f /var/log/redis_sentinel.log预期看到类似这样的日志 sdown master mymaster 192.168.1.10 6379 odown master mymaster 192.168.1.10 6379 #quorum 2/2 new-epoch 1 try-failover master mymaster 192.168.1.10 6379 vote-for-leader 8f7d3c2a5b1e460ea1f23456789abcdef 1 elected-leader 8f7d3c2a5b1e460ea1f23456789abcdef failover-state-select-slave master mymaster 192.168.1.10 6379 selected-slave 192.168.1.11:6379 failover-state-send-slaveof-noone slave 192.168.1.11:6379 failover-state-wait-promote slave 192.168.1.11:6379 promoted-slave 192.168.1.11:6379 failover-state-reconf-slave master mymaster 192.168.1.11:6379 slave-reconf-sent slave 192.168.1.11:6379 failover-end master mymaster 192.168.1.11:6379 switch-master mymaster 192.168.1.10 6379 192.168.1.11 6379日志里的关键节点是selected-slave和promoted-slave它告诉你选出了哪个从节点作为新主。最后一行switch-master表示整个故障转移完成主节点已经切换为新的地址。此时检查新主节点的状态redis-cli -h 192.168.1.11 -a your_redis_password info replication会看到role:master说明节点B已经从从节点晋升为主节点。再检查其他从节点redis-cli -h 192.168.1.12 -a your_redis_password info replication预期看到master_host:192.168.1.11说明节点C已经自动将主库切换到新主。这时候把旧主节点拉起来观察它会不会自动变成新主节点的从节点# 在节点A上启动 Redis /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf启动后自动收敛的魔法就出现了——因为哨兵已经把旧主的配置改写它会自动通过REPLICAOF连接到新主节点成为新主节点的从节点。验证方式redis-cli -a your_redis_password info replication输出中role:slavemaster_host:192.168.1.11说明旧的节点A已自动降级为从节点。4. 生产环境的关键配置与踩坑汇总能走到这一步你已经把主从哨兵的核心链路打通了。但这只是能跑离稳定跑还有一段距离。分享一些我用真金白银踩出来的坑。4.1 脑裂问题与min-slaves配置脑裂问题Split Brain是主从哨兵架构里最高频的风险。场景还原一下主节点所在的服务器因为网络分区与其他节点暂时不可达但Redis进程还在运行。哨兵集群判断主节点客观下线把从节点提升为新主。原本的主节点在隔离区里并没有意识到自己已经失势还在继续接收写入导致它在恢复后和新主节点数据不一致。如果业务在这段时间内持续写入旧主节点这部分数据就会丢失因为哨兵会将旧主降级为从节点从新主那里重新同步旧主上多出来的数据会被清空。有没有办法尽量降低这种损失有。Redis提供了min-slaves-to-write和min-slaves-max-lag两个参数# 主节点上至少需要1个健康的从节点才允许写 min-replicas-to-write 1 # 从节点数据延迟最多不超过10秒 min-replicas-max-lag 10这两个参数组合起来的意思是如果主节点发现自己当前没有在线的从节点或者所有从节点的数据延迟都超过了10秒就拒绝接收写请求返回错误。这样在脑裂发生的短时间内即使旧主还能连接写入也会被拒数据丢失范围大幅缩小。代价是可用性下降如果从节点真的全部不可达主节点也会拒绝写入。我个人的建议是在能容忍的情况下开启这个保护数据安全优先。4.2 哨兵配置的常见错误与规避错误一quorum设置过大或过小quorum设置为3但总共只有2个哨兵故障转移永远不会发生客观下线条件永远不满足。quorum设置为1任何一个哨兵误判都会触发主从切换极易造成频繁切换。错误二哨兵配置里主节点地址写错尤其是从节点上部署的哨兵如果sentinel monitor写的是从节点的地址而不是主节点的地址哨兵会把这个从节点当作主节点监控故障转移逻辑完全不生效。这个是新手最容易踩的坑。错误三三个哨兵配置的mymaster名字不一致每个哨兵文件里的sentinel monitor mymaster名字必须完全一致否则它们监控的不是同一个主节点组哨兵之间无法协同工作。4.3 Redis 6.x 密码认证的几个坑在Redis 6.0之前只有一个requirepass配置主从之间靠masterauth进行认证。Redis 6.0开始引入了ACL用户体系如果你用了ACL用户而不是默认的default用户需要注意从节点的masterauth要填正确用户对应的密码而不是简单的requirepass。比如定义了一个专门用于复制的用户密码是复制专用密码从节点的masterauth就要填这个密码。哨兵的sentinel auth-pass也要对应修改。另外如果主节点和从节点的密码不相同比如从节点单独设置了不同的requirepass哨兵在监控从节点的时候会认证失败无法正常获取从节点的状态。生产环境建议所有Redis实例使用统一的认证密码少一个变量就少一个坑。4.4 监控告警与日常巡检清单高可用不代表不需要监控哨兵本身也有挂掉的可能。我推荐的日常巡检项整理如下检查项方法正常指标Redis实例状态redis-cli pingPONG主从复制状态info replicationmaster_link_status:up数据延迟info replication对比主从offset差异小于某阈值哨兵状态sentinel master mymaster拥有有效主节点哨兵数量sentinel sentinels mymaster与部署数量一致内存使用info memoryused_memory低于maxmemory持久化状态info persistencerdb_last_bgsave_status:ok重点说下数据延迟的监控。虽然主从复制是异步的正常情况下主从延迟非常低毫秒级但一旦网络出问题或者从节点负载过高数据延迟可能飙升。建议定时脚本定期对比主从节点的master_repl_offset和slave_repl_offset差值的绝对值就是当前的复制积压量。4.5 主从同步延迟的持久优化方案如果你发现主从同步延迟始终无法收敛除了检查网络和repl-backlog-size还需要关注几个方向第一是主节点的写负载。如果主节点写QPS极高每个写命令都要同步给所有从节点网络带宽会成为瓶颈。适当的做法是增加从节点数量的同时评估主节点的网卡带宽和CPU处理能力。一般建议单主节点拖2到3个从节点比较合理如果读压力特别大可以使用多级从节点结构。第二是大Value操作。一个几十MB的Value如果频繁更新全量复制和增量同步的成本都极高。这种情况建议在业务层面拆分数据结构或者使用Hash等内存友好的结构降低单Key的体积。第三是主从部署在不同机房时机房之间专线质量差会导致同步延迟。生产环境我一般建议主从至少在同一内网跨地域场景优先考虑多主多活方案而不是主从复制。5. 最后还是分享点实在的经验搭建Redis主从哨兵这套方案本身并不复杂但如果只是照着文档把配置文件填一遍很容易在关键时刻掉链子。我见过多次线上事故都是因为某个细节没有注意到比如quorum设置有误、哨兵配置文件里的主节点地址写错了、或者没有开启min-replicas保护就发生了脑裂。根据我的经验每次部署完成后一定要做的三件事第一做一次完整的主节点宕机演练看哨兵是否能在预期时间内完成切换第二检查旧主节点恢复后是否自动降级为从节点第三用脚本监控复制偏移量确保主从数据没有延迟越积越多。这三步走完这套高可用方案才算是真正落地了。等业务量涨到数据必须分片的时候再考虑迁移到Cluster模式也不迟。