docs/high-availability/high-availability-system-design.md
高可用（High Availability，简称 HA） 描述的是一个系统在大部分时间都是可用的，可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。
一般情况下，我们使用 多少个 9 来评判一个系统的可用性，比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的，这样的系统就是非常非常高可用的了！当然，也会有系统如果可用性不太好的话，可能连 9 都上不了。
| 可用性等级 | 可用性百分比 | 年度停机时间 | 典型场景 |
|---|---|---|---|
| 1 个 9 | 90% | 36.5 天 | 个人博客 |
| 2 个 9 | 99% | 3.65 天 | 普通企业系统 |
| 3 个 9 | 99.9% | 8.76 小时 | 在线服务 |
| 4 个 9 | 99.99% | 52.6 分钟 | 金融交易系统 |
| 5 个 9 | 99.999% | 5.26 分钟 | 电信级系统 |
除此之外，系统的可用性还可以用 某功能的失败次数与总的请求次数之比 来衡量，比如对网站请求 1000 次，其中有 10 次请求失败，那么可用性就是 99%。
SLA（Service Level Agreement，服务级别协议） 是服务提供商与客户之间的正式承诺，通常会明确规定可用性目标。例如，云服务商承诺 99.95% 的 SLA，意味着每月最多允许约 22 分钟的停机时间。
导致系统不可用的原因可以从 内部因素 和 外部因素 两个维度来分析：
内部因素：
外部因素：
提高系统可用性的方法可以从 预防、容错、恢复 三个阶段来考虑：
flowchart TB
subgraph Resilience["<big>🛡️ 系统韧性三阶段<big>
"]
direction TB
%% ================= 预防 =================
subgraph Prevention["🧯 预防：把风险前置
"]
direction TB
A["🧹 质量与测试
<small>Review / 静态扫描 / 单元测试</small>"]
B["🧩 高可用架构
<small>多副本 / 多 AZ / 负载均衡</small>"]
C["🧊 缓存与本地化
<small>降延迟 / 减下游压力</small>"]
D["🧪 灰度发布
<small>Canary / 分批 / 快速回滚</small>"]
end
P2T["⬇️ 从“少出错”到“扛得住”
<small>进入故障控制面</small>"]
%% ================= 容错 =================
subgraph Tolerance["🧱 容错：隔离止血，保核心链路
"]
direction TB
E["🚦 限流
<small>令牌桶 / 并发控制</small>"]
F["⏱️ 超时与重试
<small>超时预算 / 指数退避 / 幂等</small>"]
G["🧨 熔断
<small>错误率阈值 / 半开探测</small>"]
H["🪂 降级
<small>兜底返回 / 关非核心</small>"]
I["🧵 异步与队列
<small>削峰填谷 / 解耦 / 最终一致</small>"]
end
T2R["⬇️ 从“止血”到“恢复”
<small>进入定位与处置</small>"]
%% ================= 恢复 =================
subgraph Recovery["🔧 恢复：定位修复，回到 SLO
"]
direction TB
J["📡 可观测与告警
<small>指标 / 日志 / Trace（SLI/SLO）</small>"]
K["⏪ 回滚与灾备
<small>版本回退 / 数据回放 / 切换</small>"]
end
%% 主链路
Prevention --> P2T --> Tolerance --> T2R --> Recovery
end
%% =============== 样式（统一、少而清） ===============
classDef prevent fill:#52B788,stroke:#2E8B57,color:#fff;
classDef tolerate fill:#3498DB,stroke:#2980B9,color:#fff;
classDef recover fill:#F4D03F,stroke:#D35400,color:#333;
classDef pivot fill:#2C3E50,stroke:#1A252F,color:#fff;
class A,B,C,D prevent;
class E,F,G,H,I tolerate;
class J,K recover;
class P2T,T2R pivot;
style Prevention fill:#FFF3E0,stroke:#FFCC80,stroke-dasharray: 5 5;
style Tolerance fill:#E3F2FD,stroke:#90CAF9,stroke-dasharray: 5 5;
style Recovery fill:#E8F5E9,stroke:#A5D6A7,stroke-dasharray: 5 5;
style Resilience fill:#F5F5F5,stroke:#BDBDBD,rx:20,ry:20;
代码质量是系统可用性的根基。代码质量有问题比如比较常见的内存泄漏、循环依赖都是对系统可用性极大的损害。大家都喜欢谈限流、降级、熔断，但是从代码质量这个源头把关是首先要做好的一件很重要的事情。
如何提高代码质量？比较实际可用的就是 Code Review，不要在乎每天多花的那 1 个小时左右的时间，作用可大着呢！
另外，安利几个对提高代码质量有实际效果的工具：
单点故障（Single Point of Failure，SPOF） 是高可用的大敌。先拿常用的 Redis 举个例子！我们如何保证我们的 Redis 缓存高可用呢？答案就是使用集群，避免单点故障。
当我们使用一个 Redis 实例作为缓存的时候，这个 Redis 实例挂了之后，整个缓存服务可能就挂了。使用了集群之后，即使一台 Redis 实例挂了，不到一秒就会有另外一台 Redis 实例顶上。
常见的集群模式：
限流（Rate Limiting） 是保护系统的第一道防线。其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。——来自 alibaba-Sentinel 的 wiki。
常见的限流算法包括：
一旦用户请求超过某个时间的得不到响应，就抛出异常。这个是非常重要的，很多线上系统故障都是因为 没有进行超时设置或者超时设置的方式不对 导致的。
我们在读取第三方服务的时候，尤其适合设置超时和重试机制。一般我们使用一些 RPC 框架的时候，这些框架都自带的超时重试的配置。如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法再处理请求。
重试的次数一般设为 3 次，再多次的重试没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。同时，重试需要配合 指数退避 策略，避免重试风暴。
超时和重试机制设置之外，熔断机制 也是很重要的。熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所依赖的服务恶化或者调用失败次数达到某个阈值的时候就迅速失败，让当前系统立即切换依赖其他备用服务。
熔断器有三种状态：
比较常用的流量控制和熔断降级框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。
降级（Degradation） 是在系统压力过大或部分服务不可用时，暂时关闭一些非核心功能，保证核心功能的可用性。
降级策略包括：
异步调用的话我们不需要关心最后的结果，这样我们就可以用户请求完成之后就立即返回结果，具体处理我们可以后续再做，秒杀场景用这个还是蛮多的。
但是，使用异步之后我们可能需要 适当修改业务流程进行配合，比如 用户在提交订单之后，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功。
除了可以在程序中实现异步之外，我们常常还使用 消息队列，消息队列可以通过异步处理提高系统性能（削峰、减少响应所需时间）并且可以降低系统耦合性。
如果我们的系统属于并发量比较高的话，如果我们单纯使用数据库的话，当大量请求直接落到数据库可能数据库就会直接挂掉。使用缓存缓存热点数据，因为缓存存储在内存中，所以速度相当地快！
缓存的典型应用场景：