该知识点也会分成三个篇章来介绍:高可用性的度量、高可用系统设计思路、高可用系统运维。 高可用(High availability,HA)是你在系统设计时候常用到的一个词,它指的是系统具备无故障运行的能力。 我们在很多开源组件文档中看到的HA方案就是提升组件的高可用,让系统免于宕机无法服务的方案。 比如,你知道 Hadoop 1.0 中的 NameNode 是单点的,一旦法身故障整个集群就是不可用的;而在 Hadoop2 中提出的 NameNode HA 方案就是同时启动两个 NameNode,一个处于 Active 状态,另一个处于 Standby 状态,两者共享存储,一旦 Active NameNode 发生故障,则可以将 standby node 节点切换为 Active 状态继续提供服务,这样就提升了Hadoop的持续无故障运行能力,也就提升了它的高可用。 通常来讲,一个高并发大流量的系统,系统出现故障比系统性能低更损伤用户体验。一个日活过百万的系统,一分钟的故障可能影响到上千用户。而且随着系统日活的增加,一分钟故障可能影响的用户数也会增加,系统对可用性的要求也会更高。所以今天就如何提高系统的高可用性 提供一些思路 。 可用性的度量 可用性是一个抽象的概念,你需要知道如何来度量它,与之相关的概念是:MTBF 和 MTTR。 MTBF(Mean Time Between Failure)平均故障间隔的意思,代表两次故障的间隔时间,也就是系统正常运转的平均时间。这个时间越长代表系统稳定性越高。 MTTR(Mean Time To Repair)故障的平均修复时间,也可以理解为平均故障时间,这个值越小,对用户影响越小。 可用性与 MTBF 和 MTTR 的值息息相关,我们可以用下面的公式表示它们之间的关系: Availability = MTBF / (MTBF + MTTR) 这个公式的结果是一个比例,而这个比例代表系统的可用性。一般来说我们会用几个九,来衡量系统的可用性。 通过这张图可以看到,一个九 两个九的可用性很容易达到的,只要么有蓝翔技校的叉车搞破坏,基本可以通过人肉运维的方式实现。 三个九之后,系统的故障时间锐减到 8个小时,四个九之后年故障时间锐减到52分钟。在这个级别的可用下,你可能需要建立完善的运维体系、故障处理流程、业务变更流程。你可能还需要在系统设计上有更多考虑。比如,在开发中你要考虑,如果发生故障,是否可以不需要人工介入就能自动恢复。当然了,在工具建设方面你也要多加考虑,以便出现故障能快速定位原因,让系统迅速恢复。 到达五个九之后,故障就不能靠人力恢复了。想象一下,从故障发生到你接收报警再到你打开电脑,早就十分钟过去了。这个级别的可用性是考验的你的系统容灾和自动恢复能力了,让机器来处理故障才会让你的可用性提升一个档次。 一般来说,我们核心业务系统的可用性要达到四个九,非核心业务系统最多容忍到三个九,在实际工作中,你可能听到过类似的说法,只是不同级别不同业务系统对系统的可用性要求不同。 目前,你已经对系统的可用性评估指标有了一定程度的了解,接下来的一章节我们就看下高可用的系统设计需要考虑哪些因素。