在数字存在对业务连续性至关重要的时代，高可用性（HA）的概念已成为系统设计的基石。高可用性指系统可以在长时间内连续运行而不失败。
本文探讨了高可用性的演进、如何测量、如何在各种系统中实现，以及实现它涉及的权衡。
高可用性演进
高可用性的概念起源于 1960 年代和 1970 年代的早期军事和金融计算系统，需要可靠和容错。
在互联网时代，电子商务、支付、交付、金融等的数字应用爆炸式增长。积极的用户体验对业务成功至关重要。这升级了对几乎 100% 正常运行时间的系统需求，以避免即使在短时间内也失去数千用户。例如，在促销闪购活动期间，仅一分钟停机可能导致完全失败和声誉损害。
高可用性的目标是确保系统或服务在尽可能接近 100% 的时间内可用和功能正常。虽然术语高可用性和正常运行时间有时可互换使用，但高可用性包含的不仅仅是正常运行时间测量。
测量可用性
两个关键概念与计算可用性相关：平均故障间隔时间（MTBF）和平均修复时间（MTTR）。
MTBF 通过总计系统的运行时间并除以该期间的故障次数来衡量系统可靠性。通常以小时表示。更高的 MTBF 表示更好的可靠性。
MTTR 是修复失败组件或系统并将其返回运行状态所需的平均时间。它包括诊断时间、备件检索、实际维修、测试和运行确认。MTTR 通常也以小时测量。
如下图所示，还有两个相关的指标 - MTTD（平均诊断时间）和MTTF（平均失效时间）。MTTR 可以宽松地包括诊断时间。
MTBF 和 MTTR 一起对计算系统可用性至关重要。可用性是总运行时间与运行时间和修复时间之和的比率。使用公式：
可用性 = MTBF / (MTBF + MTTR)对于高可用性系统，目标是最大化 MTBF（减少故障频率）和最小化 MTTR（从故障快速恢复）。这些指标帮助团队做出明智决策以提高系统可靠性和可用性。
几个”9”
如下图所示，计算的可用性通常用”9”讨论。实现”3 个 9”可用性每天只允许 1.44 分钟停机 - 对人工故障排除具有挑战性。“4 个 9”每天只允许 8.6 秒停机，需要自动监控、告警和故障排除。这在系统设计中增加了自动故障检测和回滚规划等要求。
要实现”4 个 9”及更高可用性，我们必须考虑：
- 系统设计 - 使用冗余和权衡设计失败
- 系统运维和维护 - 变更管理、容量管理、自动检测和故障排除
冗余架构
我们只能做这么多来优化单个实例容错。高可用性通常通过添加冗余实现。当一个实例失败时，其他实例接管。
对于有状态实例（如存储），我们还需要数据复制策略。
让我们探索具有不同形式冗余的常见架构及其权衡。
冷备架构（Hot-Cold）
在冷备架构中，有一个处理所有客户端读写的主实例，以及一个备份实例。客户端只与主实例交互，不知道备份。主实例持续同步数据到备份实例。如果主失败，需要人工干预将客户端切换到备份实例。
这种架构简单但有一些缺点。备份实例代表浪费资源，因为它大部分时间空闲。此外，如果主失败，根据最后同步时间可能有数据丢失风险。从备份恢复时，需要人工对账当前状态以确定可能丢失什么数据。这意味着客户端需要容忍潜在数据丢失并重新发送缺失信息。
温备架构（Hot-Warm）
冷备架构浪费资源，因为备份实例未充分利用。温备架构通过允许客户端从辅助/备份实例读取来优化这一点。如果主失败，客户端仍可以从辅助读取，但容量减少。
由于允许从辅助读取，主和辅助之间的数据一致性变得至关重要。即使主实例正常运行，由于请求去两个实例，也可能从读取返回陈旧数据。
与冷备相比，温备架构更适合新闻网站和博客等读重负载。权衡是在正常运行期间潜在陈旧读取，以更有效地利用资源。
热热架构（Hot-Hot）
在热热架构中，两个实例都充当主实例，可以处理读写。这提供灵活性，但也意味着写入可以发生到两个实例，需要双向状态复制。如果某些数据需要顺序排序，这可能导致数据冲突。
例如，如果用户 ID 从序列分配，用户 Bob 可能在实例 A 上获得 ID 10，而用户 Alice 从实例 B 获得相同 ID。热热架构最适合复制需求最小的情况，通常涉及临时数据，如用户会话和活动。对需要强一致性保证的数据要谨慎使用。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：How do We Design for High Availability?。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。