冗余与故障转移：无状态与有状态的不同打法
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 6 · 高可用 · 第 35/49 篇 · 🚧 占位待学
上一篇：《可用性度量：三个 9 的代价表》
下一篇：《中间件高可用盘点：MySQL、Redis、RocketMQ 与网关》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 6 · 单元 6.2
一、本文要解决的问题
机器总会坏，怎么让用户无感？无状态服务的答案简单（多副本 + 摘除），有状态的才难：数据库主挂了从库顶上，顶上的瞬间数据追平了吗？会不会两个主（脑裂）？切换中正在写的请求怎么办？
二、知识点清单
- 无状态服务故障转移：多副本 + 负载均衡健康检查摘除 + 客户端重试，转移时间 = 检测间隔
- 有状态的三类状态：数据（DB / 缓存）、连接（长连接网关）、任务（定时 / 消费位点），各自的转移难点
- 主从切换的核心问题：谁来决策（仲裁 / quorum）、数据丢不丢（RPO）、脑裂怎么防（fencing 隔离旧主）
- 优雅上下线：注册中心延迟消费（下线先摘流量再停进程）、上线预热（流量渐进），消灭发布期的错误尖刺
- 健康检查的层次：进程活着 ≠ 接口能用（就绪探针 vs 存活探针）
三、动手实验（学习时必须真跑）
- 3 副本服务编排（K8s 或 Docker + Nginx）：kill -9 一台，统计摘除期错误请求数；接入优雅停机（先摘流量后退出）再测对比
- MySQL 主从手动切换演练：从库提升为主，观察应用报错与恢复时间；故意让旧主「复活」制造脑裂观察写冲突
- 长连接网关的连接迁移实验：kill 接入节点，客户端断线重连与消息补拉
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。