高可用（High Availability），英文缩写是HA，是现代系统架构必须要衡量的一个重要指标；他指的是通过系统架构设计减少系统不能提供服务的时间。

假设系统一直能够提供服务，我们说系统的可用性是100%，如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为0.876个小时，也就不到1个小时。

保证系统高可用，架构设计的核心准则是：冗余。有了冗余之后还没完，每次出现故障需要人工介入恢复势必会增加系统的不可用时间；因此还要通过“自动故障转移”来实现系统的高可用。

数据HA是重中之重

今天我们只说数据高可用，这个才是高可用系统中最难也是最重要的模块。没有数据的高可用，其它模块的高可用只能是无源之水无本之木。

说到数据，不得不说数据库了，数据库技术本身就是针对原始文件系统特定场景的缺陷而设计的，比如：数据管理、数据安全、灵活使用、高性能、高可用等大量问题而设计的通用工具。现在大家听的最多的就是关系型数据库（MySQL、Oracle、MSSQL、PostgreSQL等）和NoSQL（Redis、MongoDB等）。无论什么样的数据库，都会有对应的HA方案。

所有主流数据库都会有自己的高可用方案，而所有方案的原理都是一样的，下面要讲的内容是数据高可用的终极问题，就三句话：

  • 方案A：数据只有一份，这一份足够安全（磁盘整列）
  • 方案B：通过实时复制，保证数据有两份（Replication）
  • 方案C：两种技术结合使用更安全（集群）

方案A

方案A是非常传统的方式，印象当中银行这种大象级公司喜欢用。大量采用2台大型机+1台高性能磁盘阵列组成的套装，磁盘阵列各种RAID级别一顿上，反正说数据大量冗余，有多么多么安全巴拉巴拉一堆…同时因为数据本身是独立的，不在应用所在服务器的主板插槽中，为了实现高速访问，还需要配置价格昂贵的光纤交换机，单光交还不行，最好来一组…

image-20201206102940562

image-20201206140549053

在我看来方案A有优点，但是缺点更多：

  1. 贵就一个字。服务器、交换机、磁盘阵列都是价格很贵的，一般小企业负担不起。
  2. 性能差。再好的磁盘阵列，再贵的光交，都不可能与挂在主板上走数据总线的方式来的快。
  3. 资源闲置。两台应用服务器只有一台工作，另外一台是备胎一直闲着，有可能终生都闲置。
  4. 脑裂风险。两台应用服务器要是没控制好，同时接管了磁盘阵列，灾难就来临了，数据可能直接损坏。当然品牌服务器都会解决这种问题的硬件模块供选配，但这种东西没有想象中的好用，切换过程非常慢。
  5. 磁盘阵列不可靠。磁盘阵列就真不会丢数据吗，无论你做啥RAID组合，磁盘阵列这台机器都启动不了，你的数据就是还在，你也只能干瞪眼。我就遇到过磁盘阵列故障开机30分钟后就自动重启的局面，还好乘机将数据copy出来了。我也亲眼见过上10个工程师在机房熬夜抢修磁盘阵列的场景。

方案B

记得阿里当年搞过声势浩大的去IOE运动，不要IBM、Oracle、EMC这些公司提供的笨重解决方法，而是选择开源的灵活的低成本方案，反而性能更好，更适合大并发量的业务类型；这种架构特定就是下面的方案B：

image-20201206103008675

方案B的有点：

  1. 价格实惠。服务器、交换机、网线都可以采用常见的设备。
  2. 多份数据。数据在不同服务器磁盘上同步，还可以控制同步安全级别，比如每条记录都同步，还是1秒同步一次等。
  3. 资源利用高。多台应用服务器可以同时利用，主用于写入，备此时可供只读查询，也不闲着。
  4. 并发好。这种架构一般都实现读写分离，可以用多台备机作为读的负载，能提供强大的服务能力。
  5. 迁移灵活。可以很容易加入更多负载服务器，实现主从切换也相对更容易。

方案B很明显，很多特点都比方案A要好，现在工具软件都采用类似这种架构设计，提供数据同步方案。现代互联网公司大都采用方案B的方式来研发部署系统。

方案C

方案B这么不错，是不是就够了呢。对一般小企业来说的确也差不多够用了，但是稍微上点规模，业务量大，影响面广了之后，会对业务系统的高可用性提出更高的要求。无论方案A或方案B，很大程度上停留在保证数据安全性上面，实际应用当中除了数据安全，还要考虑系统负载，并发吞吐量、可伸缩自动扩展、故障自动转移等很多衡量指标，此时就需要额外的软件架构来管理调度这些硬件资源，这一类的解决方案就是集群的概念，再复杂一些就要涉及分布式计算的问题。

下面我找了个Oracle官网最高可用性架构的图片来说明问题：

image-20201206103517710

方案C更像是一个把A和B糅合在一起，再加上更多的功能特点而构成的组合体。每一个小模块都有可能是方案A或方案B，然后结合组成更大的方案A或方案B。最后到跨机房的异地灾备，抽象来看就是典型的方案B模型。

总结

上面介绍的都是比较传统常见的高可用方式；现在大公司都不是这么简单单打独斗的，大量的数据中心，成片的服务器怎么管理？靠人工肯定是不行的，势必需要研发一套全自动的资源管理、分配系统。就跟中国的高铁一样，依托于实际业务需求才能造出强大的轮子，这种系统几乎肯定出自全球知名的互联网公司。这不当红分布式数据中心操作系统–K8s横空出世，大行其道；他来自谷歌绝密武器库，已经走向全球数据中心。

万变不离其宗，无论啥高可用新概论，就数据高可用这一块，都不会逃出方案A和方案B的模式；因为要么数据就一份，尽量保证这一份足够安全；要么就把数据变成两份或多份。很明显方案B比方案A有太多的优势，所以现在也是被用的最多的。但这绝不意味着方案A毫无价值，需要根据实际情况而定，也可以结合两种方案特定，设计自己的数据高可用方案。

（完）