# 可用性指标

可用性（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 系统的专用服务器，则可能连续运行几个月甚至几年时间都不出问题。另外，普通的家用路由器，跟生产级别路由器相比，更容易出现运行故障。这些都是单个组件可靠性不同导致的例子，可以通过简单升级单点的软硬件来改善可靠性。

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/blockchain_guide/04_distributed_system/availability.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.