2. 单点故障定义：严格定义、特征与判定标准
聊单点故障之前，我先问大家一个问题：一个系统里只有一个实例的服务，算不算单点故障？
很多人会脱口而出「算」。但我在实际项目中踩过坑——有些「单实例」其实根本不是单点故障，而有些看起来「多实例」的架构，反而藏着单点。所以，咱们得先把定义掰扯清楚。
2.1 严格定义
单点故障（Single Point of Failure, SPF）的严格定义是：系统中某个组件一旦失效，将导致整个系统或关键功能完全丧失可用性，且该组件不存在任何冗余或替代路径。
这个定义有三个关键词：
- 「完全丧失」——不是性能下降，不是部分功能不可用，而是整个系统或核心业务停摆。
- 「不存在冗余」——没有热备、冷备、负载均衡、故障转移等任何兜底手段。
- 「替代路径」——即使有多个实例，如果它们共享同一个底层资源（比如同一块磁盘、同一个网络交换机），那这个共享资源就是替代路径上的单点。
核心公式：
SPF = 关键功能依赖 ∩ 无冗余 ∩ 无替代路径
三者缺一不可。
2.2 四大核心特征
我总结了一套特征识别法，帮你快速判断一个组件是不是SPF。说白了，就是看它有没有这四个「死穴」：
| 特征 | 说明 | 我见过的真实案例 |
|---|---|---|
| 1. 唯一性 | 系统中只存在一个该组件实例 | 单台Nginx反向代理，后端挂了10台应用服务器也没用 |
| 2. 关键性 | 该组件失效会直接导致核心业务中断 | 数据库主库——从库再多，主库挂了写入全停 |
| 3. 无冗余 | 没有热备、冷备或自动故障转移机制 | 某次我用单节点ZooKeeper做配置中心，ZK挂了所有服务拿不到配置 |
| 4. 共享依赖 | 多个看似冗余的组件共同依赖同一个底层资源 | 两台服务器连同一个SAN存储——存储坏了，两台一起跪 |
我的经验：很多团队只检查「唯一性」和「关键性」，忽略了「共享依赖」。我曾经帮一个客户排查故障，他们明明做了双机热备，结果两台机器连同一个电源排插——保洁阿姨拔了排插，全机房断电。嗯，这就是典型的共享依赖单点。
2.3 判定标准（三步法）
怎么系统化地判定一个组件是不是SPF？我习惯用下面这个三步法，你在做架构评审时可以直接套用：
- 第一步：画依赖链
把系统从用户请求到数据存储的完整调用链路画出来。每个节点都标出来，别漏掉网络设备、中间件、DNS、证书等「隐形组件」。
- 第二步：做失效影响分析
对每个节点问自己：「如果这个节点现在立刻消失，系统还能正常服务吗？」
- 能 → 不是SPF
- 不能 → 进入第三步
- 第三步：检查冗余与替代路径
对「不能」的节点，检查：
- 是否有自动故障转移机制？
- 是否有冷备/温备可以手动切换？
- 是否有其他路径可以绕过该节点？
三者都没有 → 判定为SPF
避坑指南：我曾经判定一个Redis集群「没有单点」，因为做了主从+哨兵。结果哨兵本身只部署了一个实例——哨兵挂了，主从切换就废了。记住：冗余机制本身也可能成为新的单点。
2.4 常见误判场景
我整理了几个容易误判的场景，你对照看看自己有没有中过招：
| 误判场景 | 表面现象 | 实际单点 |
|---|---|---|
| 多实例但共享数据库 | 应用层做了负载均衡 | 数据库主库是SPF |
| 主从复制架构 | 有从库可以读 | 主库写入是SPF（如果无自动切换） |
| 多活数据中心 | 两个机房同时服务 | 全局负载均衡器（GSLB）可能是SPF |
| 容器化部署 | Pod有多个副本 | Ingress Controller或Service Mesh控制面可能是SPF |
2.5 知识结构图
下面这张图把单点故障的定义、特征和判定标准串起来了。你可以把它打印出来贴在工位上：
2.6 一个真实案例
最后分享一个我亲身经历的案例。某电商平台大促前做架构评审，技术负责人拍胸脯说「我们应用层全是多副本，没有单点」。
我多问了一句：「你们的配置中心怎么部署的？」
对方一愣：「就一个单节点Consul啊，反正配置很少变更...」
结果呢？大促当天Consul节点因为磁盘写满挂了，所有服务拿不到动态路由配置，流量全部打到已下线的旧节点上——全站502持续了40分钟。
这就是典型的「应用层冗余但基础设施层单点」。所以，判定单点故障时，别只看表面，要顺着依赖链一路挖到底。