3、单点故障与冗余设计：什么是单点故障（SPOF）、冗余设计原则、无状态服务与有状态服务的冗余策略

3.1 单点故障：那个让你半夜惊醒的“定时炸弹”

单点故障，英文叫 Single Point of Failure，简称 SPOF。说白了，就是系统里某个组件挂了，整个服务就瘫了。

我见过太多团队，上线前拍着胸脯说“我们系统很稳”，结果一台机器宕机，全员傻眼。为什么会这样？因为架构里藏着太多“隐形炸弹”。

举个例子，你有个推荐服务，所有请求都经过一台 Nginx。这台 Nginx 就是 SPOF。它一挂，用户刷不出推荐内容，业务直接归零。

我在项目中遇到过最坑的一次，是数据库主库的单点问题。当时觉得“主库挂了有从库顶上”，结果主库磁盘写满，从库还没来得及切换，整个推荐系统写不进去数据，用户画像全停。嗯，那次教训挺深刻的。

3.2 冗余设计原则：别让“多一份”变成“多一堆麻烦”

冗余不是简单堆机器。你想想看，两台机器如果配置一样、代码一样、依赖一样，那它们其实共享了同一个“故障域”。

我个人的习惯是，做冗余设计时先问三个问题：

1. 故障隔离了吗？—— 两台机器不能在同一机架、同一交换机下。
2. 流量能自动切换吗？—— 挂了之后，用户无感知才是真冗余。
3. 冗余本身会成为新 SPOF 吗？—— 比如你加了个负载均衡器，它自己挂了怎么办？

冗余设计有个黄金原则：N+1。你的业务需要 N 台机器扛住峰值流量，那就部署 N+1 台。多出来的那台，就是你的“安全垫”。

3.3 无状态服务的冗余：加机器就完事了？

无状态服务，说白了就是“不记事儿”。每次请求来了，处理完就走，不存任何上下文。

这种服务的冗余策略最简单：水平扩展。加机器、加负载均衡器，搞定。

但这里有个坑——负载均衡器本身可能是 SPOF。我建议用 DNS 轮询 + 多入口的方式。比如你在两个机房各部署一组服务，前端用 DNS 做流量分发。一个机房挂了，DNS 切到另一个。

# 无状态服务冗余示例
# 假设推荐服务是 stateless 的
# 部署架构：
# 用户 -> DNS (多A记录) -> 机房A: Nginx集群 -> 推荐服务集群(10台)
#                       -> 机房B: Nginx集群 -> 推荐服务集群(10台)

# 关键点：
# 1. 每个机房内部，Nginx 做负载均衡
# 2. 机房之间，DNS 做故障切换
# 3. 推荐服务本身无状态，任意一台都能处理请求

我记得有一次线上压测，发现无状态服务在扩容时有个“冷启动”问题。新加的机器刚上线，缓存是空的，请求进来全打到数据库。嗯，这里要注意：无状态不代表无缓存。扩容时最好预热一下，或者用一致性哈希让新节点慢慢接管流量。

3.4 有状态服务的冗余：这才是真正的“硬骨头”

有状态服务就麻烦了。它“记事儿”，比如用户会话、购物车、推荐模型参数。你不能随便加机器，因为状态在 A 机器上，请求打到 B 机器就找不到数据了。

我处理过最典型的有状态服务，是推荐系统的“用户实时特征服务”。每个用户的点击、曝光、停留时间，都实时更新到内存里。如果这台机器挂了，用户特征全丢，推荐效果直接崩。

有状态服务的冗余策略，我总结了三板斧：

3.5 实战中的“冗余陷阱”

说了这么多原则，我分享几个真实踩过的坑：

• 冗余不等于高可用—— 你配了 10 台机器，但都跑在同一个物理机上（虚拟化没做亲和性隔离），物理机一挂，全完蛋。
• 冗余增加了故障面—— 多了一个组件，就多了一个可能出问题的地方。比如你加了 ZooKeeper 做服务发现，ZooKeeper 自己挂了怎么办？
• 冗余需要演练—— 我见过最离谱的事，是冗余配好了，但从来没切过。真到故障时，发现切换脚本有 bug，切不过去。

我个人习惯是，每季度做一次“混沌工程”演练。随机杀掉一台机器，看看系统能不能自动恢复。第一次演练时，我们团队发现负载均衡器的健康检查配置错了，挂了 3 分钟才切过去。嗯，从那以后，演练成了固定流程。

3.6 总结：冗余设计的“三要三不要”

最后说一句，冗余设计不是一劳永逸的。业务在变，流量在变，你的冗余策略也得跟着变。我见过很多团队，冗余方案写进文档后就再也不看了。结果半年后，流量翻了三倍，原来的 N+1 变成了 N-1，因为那台冗余机器早就被挪作他用了。

所以，保持警惕，保持演练。这才是高可用的真谛。