什么是单点故障？如何在系统设计中消除单点？
简化版
单点故障是指系统中某个组件一旦故障，整个服务或核心链路就不可用。消除单点的核心方法是多实例冗余、负载均衡、主备切换、多副本存储、依赖降级和跨机房容灾，同时要检查隐藏单点，比如配置中心、DNS、证书、定时任务和人工操作平台。
详细版
常见单点包括：
- 只有一个应用实例或网关节点；
- 数据库只有单主无从库或无法切换；
- Redis、MQ、注册中心只有单节点；
- 所有实例部署在同一台物理机、同一机柜或同一可用区；
- DNS、证书、配置中心、对象存储、第三方接口成为隐性依赖；
- 发布系统、运维脚本、管理员账号等操作链路单点。
消除单点不能只靠“加机器”。还要保证流量能自动切到健康节点，数据有复制和恢复方案，状态组件能防脑裂，依赖失败时业务有降级策略。真正的自检方式是问：这个节点挂了，用户会不会立刻不可用？多久恢复？会不会丢数据？
完整版教学
一、单点故障的本质是“没有替代路径”
一个组件是不是单点，不取决于它贵不贵、强不强，而取决于它故障后有没有替代路径。单台高配数据库仍然是单点，因为它挂了就没有其他节点接替；一个很普通的应用实例如果后面有十几个同类实例，并且负载均衡能自动摘除故障节点，它就不是单点。
单点故障最危险的地方是平时看不出来。系统正常时，所有请求都顺着同一条路径走，大家会误以为这条路径很稳定。只有故障演练或真实事故发生时，才发现某个不起眼的组件一挂，全链路都停了。
二、应用层单点相对容易解决
无状态应用最适合多实例部署。把服务部署到多台机器或多个容器实例前面接负载均衡，某个实例挂掉后，负载均衡通过健康检查把它摘掉即可。
这里的关键是“无状态”。如果用户会话、临时文件、任务进度都存在本机内存，实例挂掉就会丢状态，流量切走也不一定正常。高可用应用通常会把状态外置到数据库、缓存、对象存储或消息队列中，使任意实例都能接手请求。
当然，状态外置后，数据库和缓存又可能变成新的单点，所以要继续向下检查。
三、有状态组件消除单点更复杂
数据库、缓存、消息队列、注册中心都属于有状态组件。它们不仅要有备用节点，还要处理数据复制、一致性、选主和故障恢复。
例如数据库主从架构中，从库可以接替主库，但前提是复制延迟可控、切换过程不会出现双主、应用路由能更新到新主。Redis 主从可以用 Sentinel 或 Cluster 做故障转移，但也要考虑数据丢失窗口。Zookeeper、etcd 这类协调系统通常依赖多数派，如果节点数和部署拓扑不合理，也会在机房故障时不可用。
因此有状态组件的高可用不能只问“有没有从库”，还要问“怎么切、切多快、切错怎么办、数据差多少”。
四、隐藏单点经常出现在依赖链路里
很多系统把主要服务做了多活，却忽略了隐藏单点。比如：
- DNS 解析异常导致用户访问不到；
- TLS 证书过期导致全站 HTTPS 失败；
- 配置中心不可用导致服务无法启动；
- 发布平台故障导致无法回滚；
- 第三方短信接口故障导致登录验证码发不出去；
- 一个定时任务只有单实例运行，挂了没人发现。
这些不是核心业务代码，但会影响核心链路。高可用排查要画完整依赖图，从用户入口一直画到数据库、缓存、消息、外部依赖和运维平台。
五、消除单点要配合演练验证
架构图上画了主备，不代表故障时一定能切成功。配置可能过期，脚本可能不可用，备用节点可能长期没有流量导致冷启动很慢，监控可能没有覆盖关键指标。最可靠的方式是定期演练。
演练可以从低风险开始：下线一台应用实例、断开某个下游依赖、模拟 Redis 主从切换、验证数据库只读切换、演练 DNS 切流。每次演练都记录恢复时间、人工步骤、数据差异和用户影响，然后改进预案。
六、排查单点要从依赖图和故障假设开始
消除单点最有效的方法是画依赖图，然后做故障假设。依赖图从用户入口开始，画出 DNS、CDN、负载均衡、网关、服务、缓存、数据库、消息队列、对象存储、配置中心、注册中心、第三方接口和发布平台。每画一个节点，就问：它挂了会影响哪些功能，有没有替代路径，切换是否自动，数据是否完整，谁会收到告警。
故障假设要具体。不要只问“数据库挂了怎么办”，要问“主库不可写怎么办、从库延迟 10 分钟怎么办、网络分区导致客户端一部分连旧主怎么办”。不要只问“机房挂了怎么办”，要问“DNS 切流多久生效、备用机房容量够不够、缓存是否预热、消息是否会重复投递”。
这个方法能暴露隐藏单点。比如应用和数据库都多副本了，但所有服务启动都依赖一个配置中心；配置中心挂了，已有服务还能跑，但扩容和重启全失败。这样的单点只有画完整链路才容易发现。
七、消除单点要配合容量和状态设计
有替代节点不等于能接管。如果备用节点容量只有主节点的 30%，切流后仍然会被打垮。如果备用数据库复制延迟很大，接管后可能丢数据。如果应用有本地状态，流量切走后用户会话可能失效。因此单点治理要同时看节点数量、容量、状态和数据。
无状态服务适合水平扩展；有状态服务要设计复制和选主；任务调度要避免同一个任务在故障切换后重复执行或无人执行；定时任务要有分布式锁、租约或调度平台。第三方依赖如果是单点，可以准备备用供应商、异步队列或人工兜底。
面试里可以把单点治理总结为四步：识别关键路径，找出不可替代节点，补冗余和切换能力，定期演练验证。这样比列举“数据库主从、Redis 集群”更完整。
八、常见误区与追问
这道题要紧扣「单点故障」本身回答，不能把它混成泛泛的高可用套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明故障域、冗余、健康检查、切换流程、RPO/RTO 和演练结果。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 单点故障是任一组件失效会导致整体不可用，治理思路是冗余部署、自动切换、依赖降级和消除共享瓶颈 | 不要停在名词解释 |
| 流程机制 | 梳理请求链路 -> 识别唯一节点或共享依赖 -> 增加副本和负载均衡 -> 设计故障切换 -> 加入降级兜底 -> 演练单点失效 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 应用 10 个实例但只连 1 个 Redis 主节点，Redis 挂了仍会导致登录或缓存链路不可用 | 高可用不是永不故障，而是用冗余、隔离、自动切换和演练降低故障影响 |
单点故障 面试拆解：
1. 梳理请求链路
2. 识别唯一节点或共享依赖
3. 增加副本和负载均衡
4. 设计故障切换
5. 加入降级兜底
6. 演练单点失效记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「单点故障」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：应用多实例就没有单点。 数据库、缓存、网关、DNS、配置中心都可能仍是单点。
- 误区：负载均衡一定消除单点。 负载均衡器本身也要高可用。
- 误区：所有单点都必须完全消除。 要按业务等级和成本评估，有些低风险单点可接受。
- 追问：怎么排查单点？ 从用户请求链路画依赖图，找唯一实例、唯一网络路径和唯一人工流程。
- 追问：单点治理手段有哪些？ 多副本、主备、集群、熔断降级、异地容灾和演练。
- 追问：共享数据库算单点吗？ 如果没有主从、备份、切换和容量冗余，就是典型单点。
九、加强记忆
判断单点就问三个问题：它挂了有没有替代节点，流量能不能自动过去，数据和状态能不能接上。单点不仅在应用和数据库里，也藏在 DNS、证书、配置、发布、定时任务和第三方依赖里。高可用设计就是不断为关键链路准备可验证的替代路径。