分布式系统高可用性设计与故障应对策略.pdfVIP

本文由简悦SimpRead转码，原文地址

高可用性是我们经常提到的名词，指系统的服务要始终可用，无论是系统运行出现故障，还是

系统的外部依赖出现问题，甚至遇到系统硬件损坏、停电等致命性打击，系统都要保证基本可用。

因此，高可用系统关注用户使用体验，并且通过降低系统出现故障的概率，以及缩短系统因故障导

致的宕机时间，减轻了开发运维人员的工作。

目前，主流的互联网产品都采用了大量来保证系统可用性，比如在双十一时会采用限流和降级

设计等手法，来保证系统能够承受住秒杀活动时产生的巨量瞬时流量；再比如，Kafka采用冗余设计将

消息备份到多个不同的Broker中，来避免消息丢失等。

那么，为了让你对系统可用性有更直观的认识，我首先带你了解分布式系统中故障不可避免的，然

后再来介绍衡量系统可用性的指标，最后介绍目前常用的高可用性设计，以帮助你学习后面的项目案例

实践打下理论基础。希望通过本节课的学习，你能够对如何设计高可用性系统有个整体的认知。

故障不可避免

高可用性是指系统的服务要始终可用，然而故障不可避免，特别是在分布式系统下，面对不的

用户流量和机房环境，系统故障将会显得更加复杂和不可预测。

在大规模的分布式系统中，各个模块之间存在错综复杂的依赖调用关系，比如前端服务依赖于后端服务

获取业务处理数据，后端服务依赖于数据库进行数据持久化处理，如果任一环节出现问题，都有可能导

致雪崩式、多米诺骨牌式故障，甚至可以断言故障的出现成了常态。

如上图的分布式系统中，用户请求查看系统中的某一个页面，请求经过服务网关转发给前端服务处理，

前端服务向后端服务请求渲染页面需要的业务数据，后端服务也可能需要从数据库中查找相关的持久化

数据，请求需要经过上述长长的调用链才能处理返回结果。也就是说，这时我们起码要保证网络连接正

常、服务网关正常、前端服务正常、服务正常、数据库正常，请求才能被正常处理。如果调用链中

的任一环节出现问题，就很可能请求出错，出现故障，这将直接影响到用户体验。

系统出现故障的多种多样，主要有以下这些：

网络问题，网络连接故障、网络带宽出现超时拥塞等；

性能问题，数据库出现慢查询、JavaFullGC导致执行长时间等待、CPU使用率过高、硬盘IO过

载、内存分配失败等；

安全问题，被网络，如DDoS等；异常客户端请求，如爬虫等；

运维问题，需求变更频繁不，架构也在不断地被调整，问题等；

管理问题，没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步；

硬件问题，硬盘损坏导致数据失败、网卡出错导致网络IO处理失败、交换机出问题、机房断

电导致服务器失联，甚至是（比如挖掘机挖断机房光缆，导致一整片机房网络中断）等。

面对如此多的和不的故障因素，系统的高可用性似乎变成不可能完成的任务，但是在日常开发

运维中，我们可以采用一些有效的设计、实现和运维来提高系统的可用性，尽量交付一个在任何时

候都基本可用的系统。

系统可用性指标

系统可用性指标是衡量分布式系统高可用性的重要因素，它通常是指系统可用时间与总运行时间之比，

即Availability=MTTF/(MTTF+MTTR)。

其中，MTTF（MeanTimeToFailure）是指平均故障前的时间，一般是指系统正常运行的时间。系统

的可靠性越高，MTTF越长，即系统正常运行的时间越长。

MTTR（MeanTimeToRecovery）是指平均修复时间，即从故障出现到故障修复的这段时间，也就是

系统不可用的时间。MTTR越短说明系统的可用性越高。

系统可用性指标可以通过下表的9999衡量，现在普遍要求至少2个9，4个9以上：

冗余设计

通过前面基础知识的铺垫，我们已经了解了系统故障的必现性以及系统可用性指标的重要性。接下来，

介绍一些典型的高可用设计，以便你知晓如何降低