2. 单点故障与冗余设计
聊容灾，第一个绕不开的词就是「单点故障」。
说白了，一个系统里只要有一个组件挂了，整个服务就瘫了——那这个组件就是单点。我见过太多团队，架构图画得漂漂亮亮，结果上线第一天，一个 Redis 节点宕机，全站 502。嗯，这就是典型的单点故障。
什么是单点故障？
单点故障（Single Point of Failure，SPOF）指的是系统中某个组件一旦失效，会导致整个系统不可用。它不一定是硬件，也可能是软件模块、网络链路，甚至是某个人——比如只有一个人会重启数据库。
常见的单点故障场景
我梳理了几个我在项目中真实踩过的坑，你对照看看自己的系统有没有类似问题。
| 层级 | 典型单点 | 后果 |
|---|---|---|
| 硬件层 | 单台服务器、单块磁盘、单路电源 | 机器宕机，服务全挂 |
| 网络层 | 单交换机、单防火墙、单 DNS | 网络隔离，请求进不来 |
| 数据层 | 单 MySQL 主库、单 Redis | 数据写入失败，缓存雪崩 |
| 应用层 | 单实例微服务、单消息队列 | 请求堆积，业务中断 |
| 人员层 | 只有一个人会修某个组件 | 人请假，系统没人管 |
我曾经在一个风控项目里，把所有的规则引擎都部署在一台 4C8G 的机器上。结果半夜流量突增，CPU 打满，整个风控判断全部超时。那晚我一边重启一边骂自己——为什么不做冗余？
冗余设计原则
冗余不是堆机器，而是有策略地消除单点。我习惯把冗余设计分成三种模式，你根据业务场景选。
1. N+1 冗余
最基础的模式。系统需要 N 个节点才能承载流量，那就部署 N+1 个。多出来的那一个，平时不干活，或者只分担少量流量。
- 适用场景： 对成本敏感，允许短时间切换
- 典型例子： 3 台 Web 服务器扛 1000 QPS，部署 4 台
- 我的经验： 我建议 N+1 的「+1」一定要做健康检查，否则它挂了你还不知道，等于没冗余
2. Active-Active 双活
两个节点同时在线，都处理流量。任何一个挂了，另一个继续扛。这是我最喜欢的模式，因为资源利用率高。
- 适用场景： 高并发、低延迟要求
- 典型例子： 双活网关、双活缓存集群
- 注意点： 数据一致性是最大挑战。两个节点同时写，冲突怎么处理？
你想想看，如果两个 Redis 同时写同一个 key，一个写 A，一个写 B，最后谁覆盖谁？所以双活通常需要「无状态」设计，或者用分布式锁兜底。
3. Active-Standby 主备
一个主节点干活，一个备节点等着。主挂了，备顶上。这种模式实现简单，但切换需要时间。
- 适用场景： 数据库、有状态服务
- 典型例子： MySQL 主从、Kubernetes 控制节点
- 我的建议： 一定要做自动切换，别等人手动操作。人半夜反应慢，而且容易出错
知识体系结构图
下面这张图帮你理清单点故障与冗余设计的核心逻辑。我习惯用这种图来给团队做培训，一目了然。
如何选择冗余策略？
我一般会问自己三个问题：
- 业务能接受多长的恢复时间？ 秒级选双活，分钟级选主备，小时级选 N+1
- 数据一致性要求多高？ 强一致性慎用双活，最终一致性可以大胆用
- 预算够不够？ 双活成本最高，N+1 最省钱
最后说一句：冗余不是万能的。你做了双活，但两个节点都在同一个机房，一个地震全完蛋。所以冗余还要考虑「物理隔离」——这是下一层的话题了。
公众号:蓝海资料掘金营，微信deep3321