第1章：多副本部署概述
为什么需要多副本？
先问个问题：你的服务如果挂了一台机器，用户还能正常用吗？
如果答案是“不能”，那你遇到的就是单点故障。我在几年前带过一个金融项目，线上只部署了一个实例，数据库也是单节点。某天半夜磁盘写满，整个系统直接瘫痪，运维同事凌晨三点爬起来扩容——那滋味，真不好受。
多副本部署，说白了就是把一套服务或数据，复制成多份，分布在不同的物理机、不同的机架、甚至不同的可用区。这样任何一个副本挂了，其他副本能立刻顶上，用户无感知。
可用性与可靠性的基本概念
这两个词经常被混用，但咱们得掰扯清楚。
| 维度 | 可用性（Availability） | 可靠性（Reliability） |
|---|---|---|
| 关注点 | 系统“能不能用” | 数据“准不准、丢没丢” |
| 典型指标 | 可用时间 / 总时间（如 99.99%） | 数据持久性、错误率 |
| 瓶颈 | 基础设施故障、网络分区 | 存储设备损坏、数据不一致 |
| 多副本作用 | 故障转移，请求切到正常节点 | 多副本冗余，单点故障不丢数据 |
举个例子：一个 Web 服务，如果后端有 3 个副本，即使挂掉 2 个，还有 1 个能处理请求——可用性高。但如果这 3 个副本用的是同一块磁盘，磁盘坏了，所有副本数据全丢——可靠性低。所以可靠性和可用性需要同时设计，缺一不可。
多副本的典型架构模式
我个人习惯把常见的模式分成三类：
- 主从复制（Master-Follower）——一个主节点写，多个从节点同步读。MySQL、Redis Sentinel 就是典型。
- 对等复制（Peer-to-Peer）——所有节点平等，可读写，通过共识算法保持一致。Cassandra、Raft 集群就是这路子。
- 灾备复制（Disaster Recovery）——跨数据中心、跨地域的异步复制，主要用来防地域性灾难。
你想想看：选哪种模式，取决于你对一致性、延迟、成本和运维复杂度的取舍。主从模式实现简单，但主节点挂了要手动推举；对等模式自动容错，但网络开销大。没有银弹。
故障转移的核心流程
多副本部署不自动等于故障转移。你得有一套机制，在副本故障时能自动切换。一般流程如下：
- 健康检测：心跳包、TCP 探活、HTTP 健康检查——每隔几秒发一次。
- 故障判定：连续几次心跳超时，或者服务返回 5xx，就标记为“不可用”。
- 仲裁与选主：如果是主从模式，剩余节点要选出新主；对等模式通常靠多数派（Quorum）来决定。
- 流量切换：负载均衡器或 DNS 把请求导向可用节点。
- 恢复与同步：故障节点恢复后，增量同步数据，重新加入集群。
这里最容易翻车的是“脑裂”问题——两个节点都以为自己是主，同时写数据，导致数据冲突。我之前在负责一个消息队列集群时，就因为心跳超时阈值设得太短，网络抖动触发了一遍又一遍的选主，结果多个节点同时充当主节点，消息顺序全乱了。嗯，那次教训让我学会了给故障切换加上必要的“冷静期”和“多数派判断”。
核心概念关系图
下面这张图能帮你把本章的知识点串起来：多副本部署是基础，目标是提升可用性与可靠性；而故障转移是实现目标的关键手段。
小结：什么时候该上多副本？
我的判断标准比较简单：
- 系统宕机超过30分钟会影响营收或用户信任——必须上。
- 系统宕机只会造成内部同事不便，且你能在上班时间修复——可以不上，但最好还是上。
- 数据丢了就无法恢复（比如没有备份）——必须多副本+跨地域备份。
最后留个思考题：如果让你设计一个只有两台机器的集群，怎么保证其中一台挂了之后服务不中断？下节课我们会动手搭一套主从复制环境，到时候你就知道答案了。