🏗️ 高可用与集群架构详解

MySQL · Redis · Elasticsearch · MongoDB · Kafka · ZooKeeper · Nacos
7 大技术的高可用方案、集群架构、选型指南、故障处理，一页讲透

① 一句话结论 ② MySQL 高可用 ③ Redis 高可用 ④ ES 集群 ⑤ MongoDB 集群 ⑥ Kafka 集群 ⑦ ZooKeeper 集群 ⑧ Nacos 集群 ⑨ 统一选型 ⑩ 生产场景 ⑪ 踩坑记录 ⑫ FAQ

① 一句话结论

高可用的本质 = 冗余 + 自动故障转移

每个技术的高可用都围绕两个问题：
① 数据怎么复制到多台机器？ → 主从复制 / 分片 / 多副本
② 主挂了怎么自动切？ → 哨兵/MHA/Zab/Raft/Paxos 等共识协议

没有银弹。 数据量小的用主从+哨兵就够了，数据量大的必须上集群。不是越复杂越好，是够用就好。

📊 7 技术高可用全景对比表

技术最小高可用方案推荐集群方案自动故障转移数据分片复杂度
MySQL 主从复制（1主N从） MGR（Group Replication）或 MHA MHA / Orchestrator 自动切 ShardingSphere / MyCat 中
Redis 主从复制（1主N从） 哨兵 Sentinel + 主从 哨兵投票自动升主 Cluster 槽位分片（16384） 中
ES 多节点 + 副本分片 原生集群（Master/Data/Coordinating） Master 选举 + 副本提升 路由算法自动分片 低→中
MongoDB 副本集 Replica Set（3节点） 副本集 + 分片 Sharded Cluster Raft 选举新 Primary Mongos 路由 + Config Server 中
Kafka 多副本 Replication（3副本） Broker 集群 + ISR 同步队列 Controller 重新分配 Leader Partition 分区 中
ZooKeeper 3/5 节点 ensemble（奇数） Zab 协议 Leader+Follower Zab 协议自动选举 无（协调服务不存大数据） 低
Nacos AP模式：Distro 协议
CP模式：Raft		 3+ 节点集群 Distro 各节点平等
Raft Leader选举		 无（注册中心/配置中心） 低
PRO TIP 面试高频考点：能说出每个技术"最小高可用配置是什么"、"自动故障转移的原理是什么"、"什么时候该升级到集群"，这三个问题答对了，高可用这块就稳了。记住：冗余 ≠ 高可用，冗余只是第一步，自动故障转移才是关键。
✅ 先知道全貌  →  接下来逐个深入 ↓

② MySQL 高可用（主从 / MHA / MGR）

MySQL 三级进化路线

阶段方案架构故障转移适合场景
Lv.1 基础 主从复制 1 主 N 从，binlog 异步同步 ❌ 手动切换（改 VIP 或 DNS） 读写分离 + 数据备份，能接受人工介入
Lv.2 进阶 MHA（Master High Availability） 主从 + MHA Manager 监控进程 ✅ 自动检测 + 自动提升最优从库为主（30s 内完成） 要高可用但不接受 MySQL 原生 MGR 的限制
Lv.3 生产 MGR（Group Replication，MySQL 5.7.17+） Paxos 协议多主/单主模式，所有节点互相同步 ✅ 自动检测 + 自动踢出故障节点 + 新主自动接管 MySQL 官方推荐方案，强一致性要求
MySQL 高可用架构演进 Lv.1 主从复制 应用 App Master (写) Slave 1 (读) Slave 2 (读) binlog 异步复制 ⚠️ 手动切换 Lv.2 MHA 应用 App Master (写) Slave 1 Slave 2 MHA Manager ✅ 自动故障检测 + 提升（~30s） Lv.3 MGR Group Replication App Node1 Primary Node2 Secondary Node3 Secondary Paxos 协议环形通信 ✅ 自动故障检测+踢出+接管

💡 核心概念速记

📦
binlog
MySQL 的二进制日志，记录所有 DML 操作。主从复制的传输载体。
⚡
GTID
全局事务 ID（5.6+），每个事务唯一标识。MGR 必须开启 GTID。
🔄
异步 vs 半同步
默认异步（快但可能丢数据）；半同步至少 1 个从 ACK 后才返回 OK（更安全）。
🎯
VIP 漂移
虚拟 IP 绑在 Master 上。Master 挂了，MHA 把 VIP 切到新 Master，应用无感知。
💡 怎么选？
• 数据量 < 50GB、并发不高 → 主从复制 + MHA（成熟稳定，社区大）
• 要强一致、不想依赖第三方工具 → MGR 单主模式（官方原生，Paxos 共识）
• 数据量巨大（TB 级） → MGR/ShardingSphere 分库分表
• 别用双主！ 双主容易主键冲突和循环复制，除非你非常清楚自己在干什么
App → VIP → Master-A (写) binlog → Master-B (备)
MHA 典型部署：双主 + MHA Manager。平时 A 写 B 备，A 挂了 MHA 把 VIP 切到 B

③ Redis 高可用（主从 / 哨兵 / 集群）

Redis 三级进化路线

阶段方案架构数据容量复杂度
Lv.1 基础 主从复制 1 主 N 从，异步复制（2.8 版本前只支持全量同步，之后支持增量） 受单机内存限制（最大 ~单机 RAM） 低
Lv.2 推荐 主从 + 哨兵 Sentinel 主从 + 3 个哨兵进程监控，主挂了投票选出新主并通知客户端 同上（仍受单机内存限制） 中
Lv.3 海量 集群 Cluster 16384 个槽位分布在多个主节点，每个主有从节点备份 理论上无限（加节点就行） 高
Redis 高可用架构演进 主从 + 哨兵（推荐起步） App Master 端口 6379 Slave 1 Slave 2 Sentinel-1 Sentinel-2 Sentinel-3 3 哨兵监控 Master → Master 下线 → 过半票选 → Slave 1 升主 → 通知客户端 Cluster 集群（海量数据） App (任意节点) 16384 个槽位分布： Master-1 槽位 0~5460 Master-2 槽位 5461~10922 Master-3 10923~16383 Slave-1 Slave-2 Slave-3 Gossip 协议交换信息 · MOVED 重定向 · ASK 临时重定向 Cluster 核心机制 • CRC16(key) % 16384 → 算出槽位 → 找到对应 Master • Master 挂了 → 从节点自动提升（不需要外部组件） • 最少 3 主 3 从（半数存活才工作），推荐 6 节点起
Redis 高可用选型口诀：
• 内存 < 16GB、QPS < 5万 → 主从 + 哨兵（简单够用）
• 内存 > 16GB 或 QPS 更高 → Cluster（16384 槽位分片，横向扩展）
• 不要混搭：用了 Cluster 就别再用 Sentinel，Cluster 自带故障检测和转移能力

④ Elasticsearch 集群架构

Elasticsearch 天然就是分布式设计的——创建索引时就自动分片。不像 MySQL/Redis 需要额外搭建集群组件。

ES 三种节点角色

角色职责资源需求生产建议
Master-eligible 管理集群状态（创建索引、分配分片、节点加入退出）。轻量，不处理数据请求 CPU 低、内存低、SSD 专门 3 台做 Master，不混用 Data 节点
Data 存放分片数据，执行 CRUD、聚合、搜索。最吃资源的角色 CPU 高、内存高（堆内存 ≥ 31GB）、SSD 根据数据量和 QPS 水平扩展
Coordinating 接收客户端请求，分发到各 Data 节点，汇总结果返回。相当于"网关" CPU 中等、内存中等 每个节点默认都是 Coordinating，大集群可独立部署
Elasticsearch 集群架构 Client / Kibana Coordinating Node(s) Data Node 1 P0 (主) R1 (副) P3 (副) Data Node 2 P1 (主) P2 (副) P4 (副) Data Node 3 P0 (副) P3 (主) P1 (副) Master Nodes ×3 管理集群元数据 索引/分片/映射 ✅ 不存业务数据! Index = 5 Primary Shards (P0~P4) × 1 Replica = 总 10 个分片 任一分片的 Primary 挂了 → 自动把对应的 Replica 提升为 Primary（秒级） 新增节点 → 自动 Rebalance（分片迁移）| 减少副本数 → number_of_replicas: 0 ES 是所有技术里"开箱即集群"做得最好的 —— 创建索引时指定分片数即可
⚠️ ES 集群常见坑
• 分片数不能随便设：每个分片开销约几十 MB 元数据。5 分片足够大多数场景，别一上来就 100 个
• JVM 堆内存 ≤ 31GB：超过 31GB 就不用 Compressed OOP 了，GC 效率骤降。-Xms31g -Xmx31g 封顶
• 别让 Master 兼 Data：Master 挂了影响集群管理；Data 满了影响查询。职责分离
• Rebalance 是双刃剑：新增节点触发大量分片迁移，可能拖垮性能。维护窗口操作

⑤ MongoDB 集群（副本集 + 分片）

MongoDB 的高可用分两层：副本集（Replica Set）解决单点故障 + 分片集群（Sharded Cluster）解决海量数据。

MongoDB 两层架构

副本集 Replica Set分片集群 Sharded Cluster
解决什么高可用 + 读写分离海量数据 + 高并发写入
最小配置3 节点（1 Primary + 2 Secondary）Mongos ×2 + Config Server ×3 + Shard ×≥2
选举协议Raft（多数派选举）每个 Shard 内部也是 Raft
数据容量单机上限（~TB 级）理论上无限（加 Shard 即可）
何时用所有 MongoDB 生产环境必备单机 > 2TB 或 写入 QPS > 万级
MongoDB 分片集群架构 Mongos Router × N（路由入口） Config Server × 3（元数据/集群配置） Shard 1（副本集） chunk range: [-∞, 100000] Pri Primary Sec1 Sec2 Raft 选举 Shard 2 [100000, 500000] Pri Sec Shard 3 [500000, +∞] Pri Sec1 Sec2 Chunk = 默认 64MB 数据块，按 shardKey 范围分布到各 Shard Balancer 在各 Shard 间迁移 Chunk（默认在低峰期运行） Primary 挂了 → Raft 选举新 Primary（~2s） | Mongos 无状态 → 可水平扩展 MongoDB 是 NoSQL 里高可用做得最好的之一 —— 副本集几乎零配置即可用
PRO TIP shardKey 选错了是最大的坑。选 _id → 所有写打到一个 Shard（热点）；选 userId → 用户均匀分布（好）；选 gender → 只有 2 个值（数据倾斜）。上线前一定要验证 shardKey 的 cardinality 和分布均匀性。

⑥ Kafka 高可用（分区 + 多副本）

Kafka 的高可用靠两套机制：Partition（分区）并行消费 + Replica（副本）容错。和别的技术不一样的是——Kafka 的副本是在 Broker 之间分布的，不是像 Redis 那样主从关系。

Kafka 核心概念

📋
Topic（主题）
消息的逻辑分类。如 order-events、user-behavior。
✂️
Partition（分区）
Topic 物理拆分成多个有序日志。提高并行度和吞吐量。
📑
Replica（副本）
每个 Partition 的完整拷贝。Leader 读写，Follower 只同步。
🔄
ISR（In-Sync Replicas）
和 Leader 保持同步的副本集合。只有 ISR 里的副本才能被选为新 Leader。
Kafka 集群架构 Producer 1 Producer 2 Topic: order-events 3 Partitions × 3 Replicas Broker 0 Broker 1 Broker 2 P0-Leader [0, 100] P1-Leader [101, 200] P2-Leader [201, 300] P1-Follow P2-Follow P0-Follow P2-Follow P0-Follow P1-Follow ISR: [Broker0, Broker1, Broker2] ✅ ISR: [Broker0, Broker1, Broker2] ✅ ISR: [Broker0, Broker1, Broker2] ✅ Consumer G1 Consumer G2 Consumer G3 Controller（某个 Broker 兼任）负责 Leader 选举和 Partition 分配
Kafka 高可用关键参数：
• replication.factor=3 — 每个分区 3 个副本（容忍 2 台宕机）
• min.insync.replicas=2 — 至少 2 个副本确认才算写入成功（保证持久化）
• acks=all — 等 ISR 中所有副本确认后才返回（最强一致性）
• unclean.leader.enable=false — 不允许非 ISR 副本成为 Leader（防数据丢失）

⑦ ZooKeeper 集群（Ensemble）

ZooKeeper 本身就是一个分布式协调服务，它的集群叫 Ensemble。ZK 的设计哲学和其他技术不同——它不存储大量业务数据，而是存储元数据/状态/配置，追求的是强一致性（CP）。

ZK 为什么必须是奇数个节点？

为什么 ZK 节点数必须是奇数？
↓
Zab 协议需要过半数（>n/2）才能达成决议
↓
2 节点 → 挂 1 个就不过半 ❌
容错 0 个
3 节点 → 挂 1 个还剩 2 个 ✓
容错 1 个（推荐起步）
4 节点 → 挂 1 个还剩 3 个 ✓
容错 1 个（浪费 1 个）
5 节点 → 挂 2 个还剩 3 个 ✓
容错 2 个（大厂标配）
结论
3 / 5 / 7 ... 奇数 = 最多容忍 (n-1)/2 台宕机
偶数节点不会增加容错能力，只会浪费一台机器
ZooKeeper Ensemble（3 节点） Client A Client B ZK-1 Leader 🎯 ZK-2 Follower ZK-3 Follower Observer 只读 ZAB 协议：Leader 广播提案 → Follower 投票确认 → 过半数通过 → Commit Observer 不参与投票，只接收广播（用于跨机房读取，降低写压力） ZNode 树: / ─── services/ ─── order-service (ephemeral) │ config/ ─── db.url (数据) │ locks/ ─── lock:order:10086 (ephemeral, seq)
💡 ZK vs 其他技术的本质区别
ZK 不是数据库、不是缓存、不是消息队列。它是分布式系统的"操作系统"——管命名、管配置、管锁、管选主。数据量通常只有 KB~MB 级别。如果发现 ZK 存了大量数据（GB 级），说明用法有问题。

⑧ Nacos 集群（AP / CP 切换）

Nacos 最独特的卖点：同时支持 AP 和 CP 两种一致性模式，可以按需切换。注册中心用 AP（可用性优先），配置中心用 CP（一致性优先）。

Nacos AP vs CP 对比

AP 模式（Distro 协议）CP 模式（Raft 协议）
协议Distro（自研，最终一致性）Raft（强一致性）
适合场景服务注册/发现（临时实例多、网络偶尔抖动）配置管理（配置不能丢、不能冲突）
一致性保证最终一致（可能有短暂不一致）强一致（多数派确认后提交）
可用性极高（部分节点挂了不影响整体）较高（需要过半数节点存活）
如何切换临时实例（ephemeral=true）自动走 AP永久实例（ephemeral=false）走 CP
Nacos 集群架构 Provider A Provider B Consumer Nacos-1 AP (Distro) + CP (Raft) port: 8848 Nacos-2 AP (Distro) + CP (Raft) port: 8848 Nacos-3 AP (Distro) + CP (Raft) port: 8848 MySQL（内置存储） 所有 Nacos 节点共享同一个 MySQL AP 模式（注册中心） 每个节点保存全部实例 定时同步，最终一致 CP 模式（配置中心） Leader 读写，Follower 同步 Raft 强一致 Nacos 2.x 支持 gRPC 长连接（替代 HTTP 心跳），性能比 1.x 提升数倍
Nacos 集群部署要点：
• 最小 3 节点（CP 模式的 Raft 需要过半数）
• 共用一个 MySQL（不是每台一个 MySQL，是所有 Nacos 节点连同一个 MySQL）
• 2.x 版本务必用 gRPC（默认开启，比 1.x 的 HTTP 心跳效率高很多）
• 配置文件用 cluster.conf 声明所有节点 IP，不要漏
✅ 7 种技术逐个讲完  →  接下来统一选型 + 生产场景 ↓

⑨ 统一选型：你的项目该怎么选？

🤔 你的系统需要哪些高可用组件？
按数据类型选技术 →
关系型数据
→ MySQL + MHA/MGR
订单/用户/交易
缓存/计数器
→ Redis + Sentinel/Cluster
Session/热点数据
全文搜索
→ ES 集群（天然分布式）
商品搜索/日志分析
非结构化文档
→ MongoDB 副本集
内容/日志/埋点
消息队列
→ Kafka 3副本+ISR
事件驱动/解耦
分布式协调
→ ZK 3/5 节点
锁/选举/配置（老项目）
注册+配置中心
→ Nacos 3 节点
Spring Cloud 项目首选

📐 经典互联网架构的高可用全景图

典型 Java 互联网架构 — 高可用全景 架 构 层 次 接入层 Nginx / SLB ×2 Gateway × N DNS → LB → Gateway → 服务 应用层 Service × N Service × N Service × N K8s Deployment 多副本 缓存层 Redis Cluster Caffeine(L1) L1本地 + L2分布式 + L3 DB 消息层 Kafka Cluster RocketMQ 异步解耦 / 削峰填谷 搜索层 ES Cluster 商品搜索 / 日志分析 / 全文检索 存储层 MySQL MGR Mongo RS 关系型 + 文档型 + 分库分表 协调层 Nacos ×3 ZK × 3 服务发现 + 分布式锁 + 配置中心
PRO TIP 不是每个项目都需要全部 7 层。小型项目：Nginx + Spring Boot + Redis + MySQL + Nacos，5 个组件就够了。中型项目加上 Kafka 和 ES。大型项目才需要全套。渐进式引入，别一开始就上满。

⑩ 生产场景模拟

🔬 场景 1：MySQL Master 宕机 — MHA 自动切换全过程

🔧 MHA Manager — 故障转移控制台
T+0s ⚠️ 告警触发
MySQL Master-A (10.0.1.10:3306) 连接超时，ping 不通
T+3s 🔍 MHA 检测
MHA Manager 通过 SSH 探测 Master-A，连续 3 次失败，判定宕机
T+5s 📊 对比 Relay Log
检查 Slave-1 和 Slave-2 的 binlog 位置，Slave-1 落后 0 秒，Slave-2 落后 2 秒
T+8s 🔄 提升 Slave-1 为新 Master
选定 Slave-1（最新）→ 执行 SLAVE STOP; RESET MASTER; → Slave-1 变成新 Master
T+12s 🔗 其余从库指向新 Master
Slave-2 和 Slave-3 执行 CHANGE MASTER TO → 指向新 Master-A (原 Slave-1)
T+15s 🌐 VIP 切换完成
VIP 10.0.1.100 从旧 Master 解绑 → 绑定到新 Master。应用端无感知恢复
当前 Master
Master-A (NEW)
原 Slave-1 · 10.0.1.11
VIP 地址
10.0.1.100 ✅
已切换到新 Master
切换耗时
15 秒
目标: < 30s
数据丢失
0 行
半同步复制模式

🔬 场景 2：Redis Cluster 从 3 主 3 从扩容到 6 主 6 从

🔴 redis-cli --cluster reshard
当前规模
3 Master + 3 Slave
6 节点 · 16GB/节点
目标规模
6 Master + 6 Slave
12 节点 · 16GB/节点
总容量
48 GB → 96 GB
翻倍 ✅
迁移进度
68%
正在迁移 slot 7500~9000
Slot 迁移实时状态
未迁移 迁移中 已迁入新节点

🔬 场景 3：ES 集群新增节点后的 Rebalance

🟢 Kibana — Cluster Health
集群状态
Green
所有分片已分配
节点数
6 → 7
+1 Data Node
分片数
10 P + 10 R
product-index
Rebalance
进行中...
预计 12 分钟
分片分配变化
分片之前位置现在位置状态
P0 (Primary)Data-1Data-1不变
R0 (Replica)Data-2Data-7 (新)已迁移 ✅
P3 (Primary)Data-3Data-3不变
R3 (Replica)Data-1Data-7 (新)已迁移 ✅
P1 (Primary)Data-2Data-2不变
R1 (Replica)Data-3Data-7 (新)迁移中...
💡 ES 的 Rebalance 只迁移 Replica 分片（除非设置 allocation enable），对线上影响较小。生产环境建议在低峰期添加节点。

⑪ 踩坑记录（真实事故教训）

坑 1：MySQL 主从延迟导致读到脏数据
现象：用户刚下了订单，查订单列表显示"暂无订单"。刷新几次后又有了。

原因：主从异步复制，写入 Master 后立刻去 Slave 读，Slave 还没来得及同步（延迟几百ms~几秒）。

解决：
• 强制读主：写操作后短时间内（如 1s 内）的同一用户请求走主库
• 半同步复制：至少 1 个 Slave 确认后才返回成功（牺牲一点性能换一致性）
• MGR 强一致模式：Group Replication 的单主模式下读写都走主节点

口诀：刚写完的数据，别急着去从库读！
坑 2：Redis Cluster 的 MOVE 重定向风暴
现象：上了 Redis Cluster 后，QPS 反而下降了 30%，大量报 MOVED 12345 10.0.0.3:6379 错误。

原因：客户端用的是普通 Jedis（不支持 Smart Client），每次访问 wrong node 都要被 Cluster 返回 MOVE 重定向，多了一次 RTT。

解决：换成 Lettuce 或 Redisson（自带 Smart Client，会缓存槽位映射表，直接找对节点）。Spring Boot 2.x 默认 Lettuce，不会有这个问题。如果是 1.x 的 Jedis，务必升级。

口诀：Redis Cluster 必须搭配 Smart Client，否则每条命令多一次往返！
坑 3：ES JVM 堆内存超过 31GB 导致 GC 灾难
现象：ES 集群经常卡顿，查询响应从 50ms 飙到 5s+，节点频繁 Full GC。

原因：运维同事给 ES 配了 -Xms64g -Xmx64g，觉得"内存大点好"。结果 JVM 超过 31GB 后停用了 Compressed Object Pointers（压缩指针），导致：
• 每个 object pointer 从 4 字节变成 8 字节，内存占用反而更多了
• GC 时要扫描的 heap 范围更大，Full GC 耗时暴涨

解决：改成 -Xms30g -Xmx30g，剩余内存留给 OS 文件系统缓存（ES 大量依赖 filesystem cache 加速查询）。

口诀：ES 堆内存封顶 31GB，剩下的给 OS cache！
坑 4：Kafka min.insync.replicas 配错导致丢消息
现象：某天一台 Broker 宕机，第二天对账发现有 ~0.01% 的支付消息丢失。

原因：min.insync.replicas 默认是 1，意味着只要 Leader 自己确认就算成功。当 Leader 所在 Broker 宕机且还没同步给 Follower 时，这部分消息就丢了。

解决：
• min.insync.replicas=2（至少 2 个副本确认）
• unclean.leader.enable=false（禁止非 ISR 副本成为 Leader）
• acks=all（Producer 等所有 ISR 副本确认）

口诀：Kafka 三件套：acks=all + min.insync.replicas≥2 + unclean.leader=false

⑫ FAQ

Q1：高可用和负载均衡是一回事吗？
不是。负载均衡（LB）是把流量分散到多台服务器，提高并发处理能力；高可用（HA）是当某台服务器挂了，系统能继续正常运行。两者经常一起用（LB 后面的服务器组本身就是一种冗余），但解决的问题不同：
• LB 解决的是"太忙了" → 并发分流
• HA 解决的是"挂掉了" → 故障转移
类比：LB 像公司招更多人手干活；HA 像给每个岗位配替补人员。
Q2：CAP 定理在实际项目中怎么取舍？
CAP 说的是：一致性 C、可用性 A、分区容错 P，三者只能选两个。但在实际中，P 是必然存在的（网络一定会分区），所以真正选的是 C 还是 A：

• 选 AP 的：注册中心（Nacos/AP）、缓存（Redis）、搜索（ES）、消息队列（Kafka）—— 短暂不一致可以接受，但不能停服务
• 选 CP 的：数据库（MySQL MGR）、配置中心（Nacos/CP）、分布式协调（ZK）、金融交易 —— 数据绝对不能错
• BASE 理论：大部分业务系统实际走的是"基本可用 + 最终一致"（Soft State + Eventual Consistency），比如下单后库存扣减通过 MQ 异步最终一致
Q3：中小公司（日活 10 万以内）需要搞集群吗？
看阶段：

阶段一（启动期）：单机就够。MySQL 单机 + Redis 单机 + Nacos 单机（开发模式）。先跑通业务。
阶段二（增长期）：加高可用。MySQL 主从 + Redis 主从哨兵 + Nacos 3 节点。成本增加不多，但能避免半夜起来救火。
阶段三（爆发期）：上集群。MySQL MGR / Redis Cluster / ES 集群 / Kafka 集群。这时候数据量和 QPS 已经撑不住了，不上不行。

核心原则：不要过早优化，也不要等到崩了再想。在增长期就把高可用搭好是最划算的时机。
Q4：这些技术的集群方案，面试怎么回答最有亮点？
面试加分回答框架（STAR 法则）：

Situation：我们项目的 XX 场景遇到了高可用问题（如 Redis 单机故障导致缓存雪崩）
Task：我负责设计高可用方案，目标是 RTO < 30s，RPO ≈ 0
Action：
• 评估了 3 种方案（主从/哨兵/Cluster），选择了哨兵（当时数据量 8GB，够用）
• 部署 1 主 2 从 + 3 哨兵，配置了半同步 + 哨兵自动故障转移
• 写了健康检查脚本对接监控系统
Result：后来确实发生过一次 Master 宕机，15s 内自动切换成功，业务无感知

关键亮点：不只是背方案，而是有"选型理由 + 具体参数 + 实战效果"
Q5：有没有一个"万能高可用模板"？
虽然每种技术细节不同，但高可用的通用模式是一样的：

步骤做什么目的
1. 冗余数据/服务复制到多台机器不把鸡蛋放一个篮子
2. 监控健康检查 / 心跳检测及时发现问题
3. 决策共识协议（Paxos/Raft/Zab/投票）多个节点达成一致
4. 动作故障转移 / 流量切换 / 提升自动恢复服务
5. 通知告警 + 客户端更新路由让人和系统都知道变化

无论 MySQL、Redis、ES 还是 Kafka，本质上都在做这 5 步。区别只在实现方式不同而已。
📚 相关专题
本页面聚焦高可用与集群架构。如果想深入了解某个技术的具体使用方法：
• Redis 专题（9 大数据结构 + redis-cli 实操 + 冷热数据 + 监控面板）
• ShardingSphere 专题（分库分表 + 读写分离 + 扩容 + 跨库问题）
• ZooKeeper 专题（ZNode / Watch / ZAB / 分布式锁 / 选举）
• Nacos 专题（服务发现 / 配置中心 / Namespace / 动态刷新）
• 缓存专题（Caffeine / 多级缓存 / 缓存穿透 / 雪崩 / 穿透）