1. 高可用不是“装个集群”就完事四个组件的选型逻辑先理清很多人一提高可用脑子里第一反应就是“上集群”。MySQL 搞个主从、Redis 弄个哨兵、MQ 搭个镜像队列、ES 配个副本分片然后觉得万事大吉。我早期也这么干过结果一次机房级故障直接把四个组件全打挂了——因为我把它们全塞在同一个机柜里交换机一抖整条链路全断。从那以后我才真正理解高可用的核心不是“有没有副本”而是“故障域有没有被真正隔离”。先把这四个组件的高可用定位说清楚不然后面全是白搭。MySQL 是有状态的关系型数据库它的高可用核心矛盾在于“数据一致性”和“切换速度”之间的取舍Redis 是内存型缓存/存储高可用的关键在于“主节点挂了之后从节点能不能快速顶上且尽量少丢数据”MQ 是异步消息中间件高可用要解决的是“消息不丢、不重、顺序不乱”这三件事在节点故障时的表现ES 是分布式搜索引擎它的高可用天然依赖分片和副本机制但真正难的是“脑裂”和“主节点选举”的稳定性。这四个组件的高可用方案市面上讲的人很多但大多数文章只告诉你“怎么配”不告诉你“为什么这么配”。比如 Redis 哨兵为什么至少需要三个节点MySQL 半同步复制到底要不要开MQ 的镜像队列和 Quorum 队列怎么选ES 的discovery.seed_hosts和cluster.initial_master_nodes到底有什么区别这些问题的答案直接决定了你的高可用方案是“真高可用”还是“看起来高可用”。我写这篇东西的出发点很简单把我这些年在这四个组件上踩过的坑、做过的取舍、验证过的方案一次性讲透。不管你是刚接触高可用的小白还是已经搭过几套集群但总在故障切换时翻车的老手都能从里面找到能直接抄作业的配置和能避开雷区的思路。全文会围绕四个组件分别展开每个组件都会讲清楚核心原理、实操配置、验证方法和踩坑经验最后再聊一下跨组件的高可用协同问题。注意本文所有配置和方案均基于通用实践具体参数需要根据你的业务量、网络环境和硬件条件做调整。不要直接复制粘贴到生产环境先在小规模环境验证。2. MySQL 高可用从主从复制到组复制到底该选哪条路2.1 主从复制最基础但也最容易翻车的方案MySQL 主从复制是所有高可用方案的基石。原理不复杂主库把 binlog 发给从库从库重放 binlog 来保持数据同步。但就是这么一个看似简单的机制在实际生产环境里能翻出无数种花样。先说过滤规则。很多人配主从的时候只写binlog-do-db或者replicate-do-db觉得这样就能只同步某个库。但这里有个大坑跨库操作时基于语句的复制SBR会导致过滤规则失效。比如你在主库执行USE db1; UPDATE db2.table1 SET ...binlog-do-dbdb1的规则下这条语句会被记录但从库重放时可能因为当前数据库上下文不对而报错或者同步错数据。我的建议是生产环境一律用基于行的复制RBR也就是binlog_formatROW。RBR 下每条变更都记录具体行的前后镜像过滤规则基于实际变更的表不会出现跨库上下文问题。再说复制模式。异步复制是默认的主库提交事务后立刻返回不等从库确认。性能最好但主库挂了可能丢数据。半同步复制semi-sync要求至少一个从库确认收到 binlog 后主库才返回能减少丢数据风险但会增加延迟。这里有个经验值如果你的业务能容忍秒级延迟半同步是值得开的。配置上需要安装rpl_semi_sync_master和rpl_semi_sync_slave插件然后设置rpl_semi_sync_master_enabledON和rpl_semi_sync_master_timeout超时后自动降级为异步。注意这个 timeout 不要设太小否则网络抖动时频繁降级反而增加主库压力。主从切换是另一个大坑。早期我用 MHAMaster High Availability做切换它能自动检测主库故障并提升从库但 MHA 有个致命问题它依赖 SSH 免密登录而且切换过程中如果原主库没彻底挂掉可能出现脑裂。后来我转向 Orchestrator它用 Raft 协议做集群管理支持自动故障检测和切换还能通过 Web 界面手动干预。Orchestrator 的核心优势是它不依赖 SSH而是通过 MySQL 协议和 HTTP API 来管理节点部署和运维都更干净。但不管用哪个工具切换后的数据一致性校验都不能省。我习惯在切换后立刻跑一遍pt-table-checksum来对比主从数据确认没有差异后再把流量切过去。这个步骤很多人会跳过觉得“切换成功就行了”但实际上一旦有数据差异后续业务逻辑可能直接错乱。2.2 组复制MGR原生高可用的正确打开方式MySQL 5.7.17 引入的组复制MySQL Group ReplicationMGR是官方原生的高可用方案。它基于 Paxos 协议实现多节点数据一致性支持自动故障检测和成员管理。MGR 有两种模式单主模式和多主模式。单主模式下只有一个节点可写其他节点只读适合大多数业务场景多主模式所有节点都可写但需要应用层处理冲突检测实际用得比较少。MGR 的核心配置项不多但每个都很关键。group_replication_group_name必须是一个合法的 UUID所有节点必须一致group_replication_start_on_bootOFF建议关掉避免节点重启后自动加入组导致意外group_replication_local_address和group_replication_group_seeds要配成节点的实际通信地址。这里有个容易忽略的点MGR 的通信端口和 MySQL 服务端口是分开的默认是 33061防火墙规则要单独放行。MGR 的故障检测是基于心跳的默认group_replication_member_expel_timeout是 5 秒。如果网络抖动超过这个时间节点会被踢出组。我踩过的坑是在跨机房部署时这个值必须调大否则机房之间的网络延迟波动会导致节点频繁被踢。一般建议跨机房场景调到 30 秒以上同时配合group_replication_autorejoin_tries设置自动重加入次数。MGR 的另一个坑是流控Flow Control。当某个节点落后太多时MGR 会触发流控限制其他节点的写入速度等落后节点追上。这个机制本意是好的但在高写入场景下会导致整个集群性能骤降。我的经验是如果业务对写入延迟敏感可以适当调大group_replication_flow_control_applier_threshold和group_replication_flow_control_certifier_threshold让流控不那么激进。但调太大又可能导致落后节点永远追不上需要根据实际写入量做权衡。2.3 读写分离与代理层别让应用直连数据库高可用方案里应用层怎么访问数据库是个容易被忽视的问题。很多团队的做法是应用直连主库从库只做备份。这种模式在主库故障时应用需要改配置重启切换时间完全取决于运维响应速度。更好的做法是引入数据库代理层比如 ProxySQL 或 MySQL Router。ProxySQL 支持读写分离、查询缓存、连接池和自动故障切换。它的核心配置是mysql_servers表里定义后端节点mysql_query_rules表里定义路由规则。比如你可以设置所有SELECT语句走从库组INSERT/UPDATE/DELETE走主库组。当主库故障时ProxySQL 会自动检测到并切换到新的主库应用层完全无感知。ProxySQL 的坑在于它的健康检查机制。默认情况下ProxySQL 通过SELECT 1来检测后端节点是否存活但这个检测只能发现“MySQL 进程挂了”这种硬故障发现不了“主从延迟过大”这种软故障。我的做法是在 ProxySQL 里配置mysql_replication_hostgroups表把主库和从库分组然后设置max_replication_lag参数。当从库延迟超过这个值时ProxySQL 会自动把它从读组里摘掉避免读到过期数据。MySQL Router 是官方出的轻量级代理配置比 ProxySQL 简单但功能也少一些。它主要配合 MGR 使用能自动发现组内的主节点和从节点。如果你的架构是 MGR MySQL Router基本可以做到应用层零配置切换。但 MySQL Router 不支持查询缓存和复杂的路由规则适合对代理层功能要求不高的场景。3. Redis 高可用哨兵、集群和云托管的三岔路口3.1 哨兵模式三个节点是底线但配置细节决定成败Redis 哨兵Sentinel是经典的高可用方案核心思路是用一组哨兵进程监控 Redis 主从节点当主节点故障时哨兵们通过投票选出新主节点并通知应用层切换。哨兵模式的关键在于哨兵数量必须是奇数且至少三个。两个哨兵的话一个挂了另一个无法形成多数派整个系统就失去故障检测能力。哨兵的配置有几个关键参数。sentinel monitor mymaster ip port quorum里的 quorum 是判定主节点客观下线的票数。比如三个哨兵quorum 设为 2意味着至少两个哨兵认为主节点挂了才会触发故障转移。这个值不能设太小否则单个哨兵的网络抖动就会触发误切换也不能设太大否则故障时无法及时切换。三个哨兵配 quorum2 是最常见的组合。sentinel down-after-milliseconds是主观下线的时间阈值默认 30 秒。这个值决定了哨兵多久没收到主节点心跳就认为它挂了。如果设得太短网络抖动会导致误判设得太长故障切换时间会拉长。我的经验是内网环境可以设 10 到 15 秒跨机房环境设 30 秒以上。sentinel failover-timeout是故障转移的超时时间默认 180 秒。这个值影响的是如果一次故障转移失败多久后重新尝试。设得太短会导致频繁重试增加系统负担设得太长会导致故障恢复时间过长。一般保持默认或者稍微调小到 120 秒都可以。哨兵模式最大的坑是客户端重定向。哨兵只负责通知应用层新主节点的地址但应用层需要自己实现重连逻辑。很多客户端库比如 Jedis支持哨兵模式会自动订阅哨兵的事件通知并重连。但如果你用的是原生 Redis 命令就需要自己处理MOVED和ASK重定向。我见过不少团队在哨兵切换后应用报错就是因为客户端没有正确处理重定向。3.2 Redis Cluster分片和高可用的双刃剑Redis Cluster 是官方原生的分布式方案它同时解决了分片和高可用两个问题。Cluster 把数据分成 16384 个槽位每个主节点负责一部分槽位每个主节点可以有多个从节点。当主节点故障时从节点会自动提升为主节点接管对应的槽位。Cluster 的配置比哨兵复杂得多。cluster-enabled yes开启集群模式cluster-config-file指定集群配置文件cluster-node-timeout是节点超时时间。这个 timeout 很关键它决定了节点多久没响应就被认为故障。默认 15000 毫秒内网环境可以调到 5000 到 8000 毫秒跨机房环境建议保持 15000 毫秒以上。Cluster 的坑主要集中在槽位迁移和脑裂上。槽位迁移是扩容或缩容时的操作如果迁移过程中有大量写入可能导致部分 key 丢失或重复。我的做法是在业务低峰期做槽位迁移并且迁移前先做一次全量备份。脑裂问题在 Cluster 里比哨兵更复杂因为 Cluster 的节点间通信是 Gossip 协议网络分区时可能出现多个主节点同时认为自己是某个槽位的主人。Redis 通过cluster-require-full-coverage参数来控制设为yes时只要有一个槽位不可用整个集群就拒绝服务设为no时部分槽位不可用不影响其他槽位。生产环境建议设为no避免单点故障导致全集群不可用。Cluster 的另一个坑是客户端兼容性。不是所有 Redis 客户端都支持 Cluster 模式。比如一些老版本的 Jedis 需要额外配置JedisCluster类而且不支持 Pipeline 和事务跨槽位操作。如果你的业务大量使用 Pipeline 或 MULTI/EXECCluster 可能不是最佳选择需要评估改造成本。3.3 云托管 Redis省心但别当甩手掌柜现在很多团队直接用云厂商的托管 Redis比如阿里云 Redis、腾讯云 Redis 等。托管服务的好处是高可用、备份、监控、扩容都由云厂商负责你只需要关注业务逻辑。但托管服务也有坑你无法控制底层的高可用策略比如故障切换的触发条件、切换时间、数据丢失窗口等都是云厂商预设的。我用过某云厂商的托管 Redis有一次主节点故障切换过程中出现了大约 30 秒的服务不可用。后来查文档才发现他们的切换策略是“先摘除故障节点再提升从节点”这个过程中客户端会收到连接错误。如果你的业务对可用性要求极高需要在应用层做重试和降级逻辑不能完全依赖托管服务。另外托管 Redis 的性能上限往往受限于你购买的规格。比如基础版可能只有单节点标准版才是主从集群版才有分片。如果你的业务写入量很大基础版或标准版可能撑不住需要提前评估。我的建议是在选托管 Redis 之前先做一次压力测试确认规格能满足业务峰值。4. MQ 高可用消息不丢、不重、不乱的三重考验4.1 镜像队列 vs Quorum 队列RabbitMQ 的路线选择RabbitMQ 的高可用方案主要有两种**镜像队列Mirrored Queue**和Quorum 队列。镜像队列是经典方案它把队列的数据复制到多个节点上主节点故障时从节点接管。Quorum 队列是 RabbitMQ 3.8 引入的新方案基于 Raft 协议实现提供更强的一致性保证。镜像队列的配置很简单在策略里设置ha-mode: exactly和ha-params: 2表示队列镜像到两个节点。但镜像队列有个致命问题它不保证强一致性。在主节点故障时如果从节点还没收到最新的消息这些消息就会丢失。而且镜像队列在节点加入或退出时会触发全量数据同步如果队列里消息很多同步过程会阻塞整个队列。Quorum 队列解决了这些问题。它基于 Raft 协议写入时需要多数派确认保证数据不丢。但 Quorum 队列也有代价它不支持部分 RabbitMQ 特性比如优先级队列、TTL 队列、死信队列的某些配置。而且 Quorum 队列的写入延迟比镜像队列高因为需要等待多数派确认。我的建议是新项目一律用 Quorum 队列除非你的业务依赖镜像队列特有的功能。Quorum 队列的配置也很简单声明队列时设置x-queue-type: quorum即可。但要注意Quorum 队列的节点数也必须是奇数且至少三个否则无法形成多数派。4.2 Kafka 的副本机制ISR 和最小同步副本Kafka 的高可用核心是副本Replica机制。每个分区可以有多个副本其中一个 Leader 负责读写其他 Follower 负责同步。当 Leader 故障时Kafka 从 ISRIn-Sync Replica列表中选出一个新的 Leader。ISR 是 Kafka 高可用的关键概念。它表示“与 Leader 保持同步的副本集合”。如果一个 Follower 落后太多会被踢出 ISR。replica.lag.time.max.ms参数控制这个阈值默认 10000 毫秒。如果 Follower 超过这个时间没追上 Leader就会被踢出 ISR。min.insync.replicas是另一个关键参数。它表示写入时至少需要多少个副本确认。比如你设置min.insync.replicas2那么当 ISR 里只剩一个副本时生产者写入会失败。这个参数配合acksall使用能保证消息不丢。但代价是如果 ISR 缩到小于min.insync.replicas整个分区就不可写。所以这个值不能设得太大一般设为副本数减一。Kafka 的坑主要在副本同步和Leader 选举上。如果副本同步跟不上ISR 会频繁收缩和扩张导致 Leader 频繁切换。我的经验是适当调大replica.lag.time.max.ms比如调到 30000 毫秒给 Follower 更多追赶时间。同时要监控 ISR 的变化频率如果频繁变化说明集群的 I/O 或网络有问题需要排查。4.3 消息不丢的完整链路从生产者到消费者MQ 的高可用不只是 Broker 端的事生产者、Broker、消费者三端都要配合。生产者端要设置acksallKafka或publisher-confirmstrueRabbitMQ确保消息被 Broker 确认后才认为发送成功。Broker 端要配置足够的副本和min.insync.replicas。消费者端要关闭自动提交 offset改为手动提交确保消息处理完成后再提交 offset。这里有个容易被忽略的点消费者手动提交 offset 的时机。如果你在处理消息的过程中提交了 offset但处理失败了这条消息就丢了。正确的做法是处理完业务逻辑后再提交 offset。但这样又可能导致重复消费如果处理成功但提交 offset 失败下次会重新消费这条消息。所以消费者端还需要做幂等处理比如用消息 ID 去重或者用数据库的唯一约束来防止重复写入。我踩过的一个坑是RabbitMQ 的publisher-confirms和publisher-returns要同时开启。publisher-confirms只能确认消息到达 Broker但如果消息无法路由到队列比如路由键写错了Broker 会返回basic.return这时候需要publisher-returns来捕获。如果只开 confirms 不开 returns消息可能静默丢失。5. ES 高可用分片、副本和脑裂的三重博弈5.1 分片和副本ES 高可用的基石ES 的高可用天然依赖**分片Shard和副本Replica**机制。每个索引被分成多个主分片每个主分片可以有多个副本分片。主分片和副本分片不会在同一个节点上这样单个节点故障时副本分片可以提升为主分片保证数据不丢。分片数的设置是个关键决策。分片太少单个分片太大查询和写入性能都会下降分片太多集群管理开销增加而且每个分片都是一个 Lucene 实例会消耗文件句柄和内存。我的经验是单个分片的大小控制在 10GB 到 50GB 之间。比如你有 500GB 数据可以设置 10 到 20 个主分片。副本数一般设为 1也就是每个主分片有一个副本这样集群总节点数至少是 2。如果要求更高可用性可以设副本数为 2但存储成本会翻倍。分片和副本的分配由 ES 的分配决策器自动完成。它会考虑节点的磁盘使用率、分片数量、节点属性等因素。你可以通过cluster.routing.allocation.*系列参数来调整分配策略。比如cluster.routing.allocation.disk.threshold_enabledtrue开启磁盘水位线控制当节点磁盘使用率超过cluster.routing.allocation.disk.watermark.high默认 90%时ES 会把分片迁走。这个机制能防止磁盘写满导致节点故障但也要注意如果所有节点磁盘都超过水位线分片就无法分配集群会变成红色状态。5.2 脑裂问题ES 集群最危险的故障脑裂是 ES 集群最危险的故障模式。当集群网络分区时如果两边都选出了主节点就会形成两个独立的集群各自接受写入导致数据不一致。ES 7.x 之前脑裂问题比较常见因为主节点选举是基于minimum_master_nodes参数的。如果这个参数设得太小网络分区时两边都可能选出主节点设得太大主节点故障时又无法选出新主节点。ES 7.x 引入了基于 Raft 的集群协调层彻底解决了脑裂问题。新的协调层不再依赖minimum_master_nodes而是通过cluster.initial_master_nodes来指定初始主节点候选列表。这个列表只在集群第一次启动时使用之后集群会自己维护主节点列表。配置上要注意cluster.initial_master_nodes只在第一次启动时设置之后必须删掉否则集群重启时可能出问题。discovery.seed_hosts是另一个关键参数它指定了集群发现时的种子节点列表。这个列表不需要包含所有节点但至少要包含部分主节点候选。ES 节点启动时会通过这个列表找到其他节点然后加入集群。如果这个列表配错了节点可能无法加入集群或者加入错误的集群。5.3 快照和恢复高可用的最后一道防线不管你的集群多稳定**快照Snapshot**都是必须的。快照是 ES 的备份机制它把索引数据备份到外部存储比如 S3、HDFS、NFS。当集群发生不可恢复的故障时可以从快照恢复数据。快照的配置需要先注册一个快照仓库。比如用 S3 作为仓库需要安装repository-s3插件然后在elasticsearch.yml里配置 S3 的访问密钥和区域。注册仓库的命令是PUT _snapshot/my_backup指定仓库类型和配置。创建快照的命令是PUT _snapshot/my_backup/snapshot_1?wait_for_completiontrue可以指定要备份的索引。快照的坑主要在恢复过程上。恢复快照时ES 会把快照里的分片分配到集群节点上。如果集群的节点数少于快照里的分片数恢复会失败。所以恢复前要确保集群有足够的节点。另外恢复过程中会占用大量 I/O 和网络带宽建议在业务低峰期做。我的经验是定期做快照恢复演练确保快照是可用的而不是等到真出事了才发现快照损坏。6. 跨组件协同高可用的最后一公里6.1 故障域隔离别把鸡蛋放在一个篮子里前面讲的都是单个组件的高可用但真正的高可用需要跨组件协同。最基本的原则是故障域隔离。如果你的 MySQL 主库、Redis 主节点、MQ 主节点、ES 主节点都在同一台物理机上那这台机器一挂四个组件全挂。所以部署时要确保同一组件的不同角色节点分布在不同物理机、不同机柜、甚至不同机房。跨机房部署时网络延迟是个大问题。MySQL 的半同步复制在跨机房时延迟会明显增加可能需要降级为异步复制。Redis 的哨兵在跨机房时down-after-milliseconds要调大否则网络抖动会导致误切换。MQ 的副本同步在跨机房时ISR 收缩会更频繁需要调大replica.lag.time.max.ms。ES 的跨机房部署更复杂因为分片分配要考虑机架感知cluster.routing.allocation.awareness.attributes确保主分片和副本分片不在同一个机架。6.2 监控和告警高可用的眼睛没有监控的高可用就是盲人摸象。每个组件都需要监控关键指标MySQL 要监控主从延迟、连接数、慢查询Redis 要监控内存使用率、命中率、主从偏移量MQ 要监控队列深度、消息堆积、ISR 变化ES 要监控集群状态、分片分配、JVM 堆内存。告警阈值要根据业务特点来设。比如 MySQL 主从延迟超过 10 秒告警Redis 内存使用率超过 80% 告警MQ 队列深度超过 10 万告警ES 集群状态变成黄色或红色告警。告警要分级警告级别可以发邮件或即时通讯消息严重级别要发短信或打电话。我见过不少团队监控配了一堆但告警发到群里没人看最后故障了才发现。所以告警一定要有明确的责任人和升级机制。6.3 演练高可用的试金石最后也是最重要的一点定期做故障演练。你可以手动杀掉 MySQL 主库进程看切换是否正常可以断开 Redis 主节点网络看哨兵是否触发切换可以停掉 MQ 的一个 Broker看消息是否丢失可以关掉 ES 的一个节点看分片是否重新分配。演练的目的是发现高可用方案里的隐藏问题。比如你可能发现MySQL 切换后应用没有重连、Redis 哨兵切换后客户端没有更新配置、MQ 副本同步太慢导致消息丢失、ES 分片恢复时间太长影响查询。这些问题在平时不会暴露只有演练时才会浮现。我的经验是每季度至少做一次全链路故障演练把发现的问题记录下来逐个修复然后下次演练再验证。提示演练前一定要做好数据备份并且选择业务低峰期进行。演练过程中要有回滚方案一旦影响业务立刻恢复。这四个组件的高可用方案每一个都有无数细节可以深挖。我在这篇里尽量把核心原理、关键配置和踩坑经验都讲到了但受限于篇幅还有一些高级话题没有展开比如 MySQL 的 MGR 流控调优、Redis Cluster 的槽位迁移策略、Kafka 的机架感知配置、ES 的冷热分层架构等。如果你对某个点特别感兴趣可以顺着本文提到的参数和工具去查官方文档或者在小规模环境里自己动手验证。高可用这件事看再多文章都不如自己搭一遍、挂一次、修一次来得深刻。