3. 高可用设计原则：冗余设计、故障隔离、优雅降级、无状态化与有状态化的权衡
各位好，我是老赵。今天咱们聊聊高可用设计里最核心的几个原则。说实话，这些原则我早年做单体应用时根本没当回事，直到线上出了几次大故障，才真正体会到什么叫「纸上得来终觉浅」。
高可用不是靠运气，而是靠设计。你想想看，一个系统跑在线上，随时可能遇到网络抖动、磁盘写满、CPU 飙高、甚至机房断电。没有一套成熟的设计原则兜底，再牛的架构也是纸老虎。
我个人习惯把高可用设计拆成五个维度：冗余、隔离、降级、无状态化、有状态化权衡。咱们一个一个说。
3.1 冗余设计：别把所有鸡蛋放一个篮子里
冗余，说白了就是「多备几份」。我见过不少团队，线上只部署一个实例，美其名曰「节省成本」。结果一次机房故障，整个服务全挂。嗯，这种教训太贵了。
冗余设计有几个关键点：
- 多副本部署：至少两个副本，最好跨可用区。比如 Kubernetes 里用 Deployment 控制多个 Pod，配合 PodAntiAffinity 让它们调度到不同节点。
- 数据冗余：数据库主从、Redis 哨兵、Kafka 副本机制。数据丢了，比服务挂了更可怕。
- 链路冗余：网络层面多链路、DNS 多 IP、负载均衡多节点。
核心原则：冗余不是简单的「多复制一份」，而是要确保冗余副本之间没有共享的单点故障。比如两个 Pod 跑在同一台物理机上，那就不叫真正的冗余。
我在项目中遇到过一件事：某次大促前，我们给核心服务做了 3 副本部署，结果压测时发现其中一个副本的响应时间特别慢。排查下来，原来是那个 Pod 和另一个高负载服务共享了宿主机。你看，冗余设计不仅要考虑「有没有」，还要考虑「好不好」。
3.2 故障隔离：别让一个坏苹果坏了一整筐
故障隔离，就是要把问题控制在最小范围内。我经常跟团队说一句话：「一个服务挂了，别把整个系统拖下水。」
常见的隔离手段：
- 进程隔离：每个服务独立进程，别搞大单体。微服务架构天然支持这一点。
- 线程池隔离：Hystrix 或者 Sentinel 的线程池隔离模式，让不同接口用不同的线程池。一个接口慢，不会占满所有线程。
- 资源隔离：CPU 绑核、内存限制、磁盘 IO 限速。Kubernetes 的 Resource Quota 和 Limit Range 就是干这个的。
- 故障域隔离：不同服务部署在不同的故障域（机房、机架、交换机）里。
避坑指南：我曾经在一个项目里，把所有中间件的客户端连接都放在同一个连接池里。结果 Redis 挂了，导致所有数据库查询也跟着超时。这就是典型的「隔离没做好」。后来我们给每个中间件单独建连接池，问题就解决了。
为什么会这样？因为故障是会传播的。一个组件出问题，如果隔离没做好，就会像多米诺骨牌一样，一个接一个倒下。所以，隔离的本质是「切分故障边界」。
3.3 优雅降级：有总比没有好
降级，就是当系统扛不住的时候，主动放弃一些非核心功能，保住核心功能。说白了，就是「有总比没有好」。
我见过最典型的场景：双十一大促，商品详情页扛不住了。这时候，把「用户评论」「相关推荐」这些非核心模块降级掉，只展示商品基本信息。用户虽然体验差了点，但至少能下单。
降级策略一般分几种：
- 页面降级：返回静态页面或缓存数据，不查数据库。
- 功能降级：关闭某些非核心功能，比如日志上报、消息推送。
- 数据降级：从实时数据降级为离线数据，或者从精确数据降级为近似数据。
个人经验：降级开关一定要做成配置中心动态下发，别写死在代码里。我见过有人把降级开关写在配置文件里，每次改完还要重启服务。等重启完，故障已经结束了。嗯，这很尴尬。
降级还有一个关键点：降级后要能自动恢复。不能降级了就永远回不来了。我建议用「熔断器」模式，比如 Sentinel 的熔断降级，当错误率达到阈值就熔断，过一段时间自动半开尝试恢复。
3.4 无状态化：云原生的基石
无状态化，是云原生架构里我最推崇的设计理念。为什么？因为无状态的服务可以随意扩缩容，随便重启，随便迁移。你想想看，一个服务如果依赖本地磁盘上的 Session 数据，那它还能随便漂移吗？不能。
无状态化的核心做法：
- Session 外置：把 Session 存到 Redis 或数据库里，别放在本地内存。
- 配置外置：配置信息放到配置中心（Nacos、Apollo、Consul），别写死在代码里。
- 日志外置：日志直接打到 ELK 或 Loki，别留在本地磁盘。
- 文件外置：上传的文件存到 OSS 或 S3，别放本地。
一句话总结：无状态化就是「把状态交给中间件，让应用只负责计算」。
我在项目中遇到过一个问题：有个老系统，用户登录状态存在本地 Session 里。每次扩容新实例，用户都要重新登录。后来我们改成用 Redis 存 Session，问题就解决了。你看，这就是无状态化的价值。
3.5 有状态化的权衡：不是所有东西都能无状态
但是，我必须说一句大实话：不是所有东西都能无状态化。数据库、消息队列、缓存，这些中间件天生就是有状态的。你不可能让 MySQL 变成无状态，对吧？
所以，我们需要在有状态和无状态之间做权衡。我的建议是：
- 应用层尽量无状态：业务服务、网关、聚合层，这些尽量做成无状态。
- 数据层接受有状态：数据库、缓存、消息队列，这些天然有状态，我们要做的是让它们「高可用」而不是「无状态」。
- 中间层做状态转移：比如用 Redis 做 Session 存储，把应用层的状态转移到中间件层。
| 组件类型 | 推荐设计 | 原因 |
|---|---|---|
| 业务服务 | 无状态 | 方便扩缩容、滚动更新 |
| API 网关 | 无状态 | 路由和限流不依赖本地数据 |
| MySQL | 有状态 + 主从复制 | 数据持久化，无法无状态 |
| Redis | 有状态 + 哨兵/集群 | 缓存数据在内存，需要高可用 |
| Kafka | 有状态 + 副本机制 | 消息持久化，保证不丢 |
注意：有状态组件的高可用，核心是「数据不丢 + 服务不中断」。比如 MySQL 用主从复制 + 半同步，Redis 用哨兵自动切换，Kafka 用 ISR 副本机制。这些我在后面的章节会详细讲。
3.6 知识体系总览
说了这么多，我画了一张图，把这五个原则的关系梳理了一下。你一看就明白了。
这张图把五个原则串起来了。你看，冗余和隔离是基础，降级是应急手段，无状态化是理想目标，有状态化是不得不面对的 reality。它们不是孤立的，而是一个整体。
好了，这一章就到这里。记住一句话：高可用不是靠运气，而是靠设计。下一章咱们聊聊具体的中间件高可用方案，从 Redis 开始。