> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/blockchain_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/blockchain_guide/04_distributed_system/availability.md).

# 可用性指标

可用性（Availability）是描述系统在需要时能成功提供服务的比例的重要指标，常用百分比或请求成功率衡量。可靠性（Reliability）更强调系统在规定条件和时间内正确工作的能力；高可靠通常会提高可用性，但两者不是同一个概念。高可用的分布式系统往往需要各种复杂的机制来进行保障。

通常情况下，服务的可用性可以用服务承诺（Service Level Agreement，SLA）、服务指标（Service Level Indicator，SLI）、服务目标（Service Level Objective，SLO）等方面进行衡量。

## 几个 9 的指标

完美的可用性是不存在的。很多领域里谈到服务的高可用性，通常都会用“几个 9”的指标来进行衡量。

“几个 9”的指标，其实是概率意义上粗略反映了系统能提供服务的可用性指标，最初是电信领域提出的概念。

下表给出不同指标下，每年允许服务出现不可用时间的参考值。

| 指标   |       可用性 | 每年允许不可用时间 | 典型场景 |
| ---- | --------: | --------: | ---- |
| 一个 9 |       90% |    1.2 个月 | 简单测试 |
| 二个 9 |       99% |     3.6 天 | 普通单点 |
| 三个 9 |     99.9% |    8.6 小时 | 普通集群 |
| 四个 9 |    99.99% |   51.6 分钟 | 高可用  |
| 五个 9 |   99.999% |      5 分钟 | 电信级  |
| 六个 9 |  99.9999% |      31 秒 | 极高要求 |
| 七个 9 | 99.99999% |       3 秒 | N/A  |

一般来说，单点的服务器系统至少应能满足两个 9；普通企业信息系统应能满足三个 9；少数领先企业（如亚马逊、甲骨文）产品能实现四个 9 甚至更多。大型金融和电信系统指标是五个 9，意味着每年最多允许出现五分钟左右的服务故障。五个 9 以上的系统十分罕见，要实现往往意味着极高的成本。

## 两个核心时间

一般地，描述系统出现故障的可能性和故障出现后的恢复能力，有两个基础的指标：MTBF 和 MTTR。

* MTBF：Mean Time Between Failures，平均故障间隔时间，即系统可以无故障运行的预期时间。
* MTTR：Mean Time To Repair，平均修复时间，即发生故障后，系统可以恢复到正常运行的预期时间。

MTBF 衡量了系统发生故障的频率，如果一个系统的 MTBF 很短，则往往意味着该系统可用性低；而 MTTR 则反映了系统碰到故障后服务的恢复能力，如果系统的 MTTR 过长，则说明系统一旦发生故障，需要较长时间才能恢复服务。

一个高可用的系统应该是具有尽量长的 MTBF 和尽量短的 MTTR。

## 提高可用性

那么，该如何提升可用性呢？有两个基本思路：一是让系统中的单个组件都变得更可靠，以提高 MTBF；二是干脆消灭单点，并通过自动恢复缩短 MTTR。

IT 从业人员大都有类似的经验，普通笔记本电脑，基本上是过一阵可能就要重启下；而运行 Linux/Unix 系统的专用服务器，则可能连续运行几个月甚至几年时间都不出问题。另外，普通的家用路由器，跟生产级别路由器相比，更容易出现运行故障。这些都是单个组件可靠性不同导致的例子，可以通过简单升级单点的软硬件来改善可靠性。

然而，依靠单点实现的可用性毕竟是有限的。要想进一步提升，那就只好消灭单点，通过主从、多活等模式让多个节点集体完成原先单点的工作。这可以从概率意义上改善服务对外整体的可用性，这也是分布式系统的一个重要用途。