高可用：这个保险值得买

本文首发微信公众号：飞总聊IT

2023年1月11日美国东部时间上午6点29分，美国航空监管机构FAA发布了一条通告，随后不久，很快就宣布美国国内所有航班都停飞了。通告的内容是，FAA正在对NOTAM（Notice to Air Mission）系统进行验证和回复。

这是美国自2001年911袭击以来首次出现如此大规模的停飞。当天晚上18点31分钟，FAA宣布这次停飞是因为NOTAM系统数据库文件受损导致的。

这件事情引起的直接和间接经济损失难以估量。然而该系统实际出问题的原因却令人啼笑皆非。该系统没有高可用的架构，在一次计划的维护过程中，一位工程师的操作导致了数据库文件被破坏，最终导致了这次全美国飞机停飞的事故。

这故事听起来非常的熟悉，MOTAM是一个古老的系统，有一个古老的数据库系统。这个数据库系统，没有任何高可用的实现。在IT技术发达的美国，这不得不说是个笑话。

现实中，大部分的商业数据，不是这样的。比如说我们常见的金融系统，都需要两地三中心的高可用架构的部署。什么是高可用呢？简单来说，就是通过系统内部的冗余设计，当一部分东西因为某种原因无法工作的时候，系统内冗余的部分可以接管系统，继续正常运行。

这种高可用的系统，带来的便利性是显而易见的。以上面的NOTAM系统为例，如果系统采用了高可用的设计和部署的话，那么当一个数据库无法服务的时候，备份数据库可以立刻接管系统，所以就不会出现全美国的飞机都停飞12个小时这样重大的事故。

高可用是怎么样提高系统的可用性的呢？我们为了获得高可用，又需要付出什么样的代价呢？我们简单分析一下。

在数据库里面最简单的高可用实现可以通过主备机来实现，系统由一台主机和若干台备机，主机服务业务，支持读写，备机从主机这里获得数据同步，可以不参与业务，或者只读。当主机出问题的时候，其中的一台备机就升级成为主机，接替出问题的主机继续提供服务。

我们来分析一下加入备机是怎么样提高系统的可用性的。假设1台机器99%的时间正常工作，1%的时间能因为断电，地震，硬件故障，病毒感染，软件故障，系统维护等等原因不工作。

如果我们只有主机的话，正常服务的时间是99%。

现在我们加入一台备机，总共两台机器。在最理想的情况下，我们假设网络等其他外围设备100%工作正常，我们同时假设两台几千相互独立，一台机器的好坏和另外一台机器无关。那么只有当两台机器都不工作的时候，系统才不工作。

而两台机器都不工作的概率是1%x1%=0.01%，所以系统工作的时间是1-0.01%=99.99%。增加一台备机让系统的工作时间从99%提升到了99.99%。

当然这只是理想情况，现实中没有那么美好，比如说网络可能不工作。又比如说两台机器的好坏是相关的。

有人可能不理解，为什么两台机器的好坏相关呢。我举几个例子。比如说两台机器在同一个机房，正好机房着火了。比如说两台机器在同一个机柜，机柜的电源烧了。比如说，两台机器同一批次买的，结果这个批次的机器内存有缺陷。

我们也可以算出来最坏的情况下，增加一台备机让系统时间到底提高多少，最坏的情况下，就是两台机器的好坏100%相关，一台机器不工作的时候另外一台机器必定不工作，反之亦然。这个时候，系统坏的概率就等于主机坏的概率，就是1%，整个系统99%的时间工作正常。

所以现实中，增加一台机器，系统的实际提升在99%到99.99%之间。

如果我们想进一步提升系统的可用性，也是可以的，只要再增加一点冗余就可以了，在这种主备机的冗余设计下， 再增加一台备机可以更多的增加系统的服务时间。

上述分析说明了几个关于高可用的事实。我总结一下。

第一，高可用是以增加系统的冗余来实现的，冗余就需要额外的成本。但是如果系统不可用的代价很大，比如说，美国全国飞机停飞12个小时，而增加的成本对比系统不可用的代价很小，那么，这样做就是值得的。从这个角度看，高可用像是买保险。

第二，增加系统的冗余，可以让系统的可用性变得更高，但是，代价是成本也更高，如果成本的付出超过了系统不可用的代价的话，这种高可用是不是必须实现，是值得商榷的。

第三，任何的高可用实现，都只能提高整个系统的可用性，但是没有任何一种高可用的实现，能够保证系统100%可用。这说明，我们不要有部署了高可用的实现就可以让系统永远不崩溃这样的不切实际的幻想。从某种程度上来说，高可用更像买保险，以比较小的代价确保大概率不至于付出很大的代价。

高可用的部署，还有一个问题，就是我们希望这些冗余的东西的相关性尽可能的低。比如说，当你把主机和备机放在同一个机柜的时候，就不太好，放在同一个机房的不同机柜就好一点。放在不同的机房就更好。放在不同城市的不同机房就更好了。

又比如说，你希望主机和备机最好不是同一批机器，不然的话，它们容易遇到同样的问题。容易用了同样的时间一起硬件坏。总之我们可以列出很多需要做的事情。

这么多的要求，对于一个大企业来说还好，对小企业来说，要想做到尽善尽美是很难的。如果偷懒只是在一个机房的同一个机柜里面上两台同一批次的机器做主备的话，那这个高可用的实现，效果可能就不会太理想了。

但是云计算时代就不一样了。在云上，一方面，云厂商的机器的选择空间很大，可以在不同的机房不同的城市。另外一方面，云厂商也服务了大量的客户，有成熟完备的高可用实现。所以进入到云计算时代，高可用的实现，对客户来说也就变得接地气起来。

可以这样说，正是因为有了云计算，有了公有云厂商，现在高可用对小客户来说才有了比较靠谱的实现。

很多客户对上云还是有比较错误的理解，有些人觉得，只要我的应用上云了，我的数据库上云了，那么云厂商就自动的保证我的应用，我的数据库一直持续稳定运行下去了。

这并不是云计算的真实情况。举个例子，如果客户在公有云平台租用了一台虚拟机，那么这和用户自己买了一台物理机放在本地机房并没有什么区别。部署在虚拟机上的数据库和应用，也会因为各种各样的原因而无法运行。

有的用户因此就觉得是云厂商的责任，乃至去打官司。但是这种官司往往并不能胜诉。因为在云厂商上的应用，也需要和物理机一样，选择了高可用架构以后才能获得高可用的保证。单纯的使用云，并不能保证该应用或者数据库就可以一直无障碍地运行下去。

对于云上的数据库，如何设计高可用架构。一般来说，很多时候我们需要考虑如下三步走。

首先，我们需要建立基于Master-Slave的HA架构，简单的应用，我们需要一个主机，一个备机。如果需要更高的可靠性的时候，可以通过一主机多备机的做法来实现。

我们不但需要有主机和备机，也需要在这个架构上保证主机不再提供服务以后，切换到备机的速度很快，这样前台的应用就不至于受到影响。以饿了么为例，根据饿了么发布的技术文档显示，这种切换需要在30秒内完成。

其次，如果数据量很大的话，就需要对数据进行分片处理。分片处理的好处是，如果其中一个片发生了问题，并不会影响到其他部分的数据。假如我们对数据进行了十个分片，那么一个机器出现故障时，对业务的影响只有十分之一。

理论上来说，分片足够小，配合主机和备机的架构，业务的影响就会更小，架构对应用来说也就更高可用。但是从另外一个角度来说，过小的分片，也会影响访问速度，而且，过多的分片也会带来成本的考虑，毕竟增加分片意味着需要更多的虚拟机，也就增加了运行成本。

最后，通常对数据库的可靠性要求高的应用，需要做异地多活。比如说银行的数据库系统，通常采用两地三中心的部署方案。这是什么意思呢？简单来说，我们的数据放三份拷贝，一个主机和两个备机，其中有一个备机确保在和主机异地的机房里，另外一个备机在和主机同一个城市的机房里。

这样做的好处有两个方面，一方面，如果主机的数据坏了，切换过去的时候先切换本地的备份，速度比较快。同时又保留了一个异地的备份，如果因为地震，断电等涉及一个城市但通常不会波及到另外一个城市的灾难，这种方式也可以保证应用还有一个数据拷贝支撑，继续运行。这样可以提供更高的高可用性。

当然，理论上来说，异地多活，可以在多个异地做多活，而一旦做了多个异地的多活，我们的高可用的可用性就更高了，除非这几个异地的机房全部都不工作了，否则应用总是可以继续运行下去的。

那么现实中，我们为什么不做这种选择呢？其实现实中，我们也不会对数据做很细的切片。这两者的出发点都是一样的，为了获得更好的高可用，我们就需要投入更多的资源。

比如说，两地三中心的一主两备投入的资源，和五地八中心投入的资源，显然是没办法比的。把数据切成100份和切成10份需要花费的代价也不一样。

而且高可用的投入还有这样一个特点，为了获得更好的高可用，投入的资源并不是线性增长的。举例来说，假设现在的高可用是99.99%，投入的资源增加一倍，可以变成99.999%，再投入三倍的资源啊可以达到99.9999%。那么是不是值得投入更多的资源来获得更好的高可用呢？

这个问题通常来说，是不值得的。当我们的高可用达到足够高的时候，投入的资源和获得的收益会是很好的一个投入产出比的问题。而实践中，云厂商的很多解决方案，往往已经都是经过实际检验的，有比较好的投入产出比。

当然这也再次回答了我们文章前面提到的，高可用更像是一个保险，用比较小的投入，大概率的避免较大的损失。但是，即使使用了高可用的设计，也不代表这个系统100%不会罢工。所以，高可用这个保险，你觉得是不是值得买呢？