「高可用」通常用 2 个指标来衡量：
- 平均故障间隔 MTBF（Mean Time Between Failure）：表示两次故障的间隔时间，也就是系统「正常运行」的平均时间，这个时间越长，说明系统稳定性越高
- 故障恢复时间 MTTR（Mean Time To Repair）：表示系统发生故障后「恢复的时间」，这个值越小，故障对用户的影响越小
可用性与这两者的关系：
可用性（Availability）= MTBF / (MTBF + MTTR) * 100%
故障一般体现在 3 个方面：
- 硬件故障：CPU、内存、磁盘、网卡、交换机、路由器
- 软件问题：代码 Bug、版本迭代
- 不可抗力：地震、水灾、火灾、战争
后台服务可以划分为
两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过 F5 或者任何代理的方式就可以很好的解决。
本文描述的主要是针对有状态的服务进行分析。
服务端进行状态维护主要是通过磁盘或内存进行保存，如 MySQL 数据库，redis 等内存数据库。除了这两种类型的维护方式，还有 jvm 的内存的状态维持，但jvm的状态生命周期通常很短
1、方案概述：
高可用的一些解决方案
- 冷备
- 双机热备
- 同城双活
- 异地双活
- 异地多活
1.1 冷备
冷备，通过
停止数据库对外服务的能力，通过文件拷贝的方式将数据快速进行备份归档的操作方式。简而言之，冷备，可以理解为复制粘贴，在 linux 上通过 cp 命令就可以很快完成。可以通过人为操作，或者定时脚本进行。
优点：
简单快速备份（相对于其他备份方式）快速恢复。只需要将备份文件拷贝回工作目录即完成恢复过程（亦或者修改数据库的配置，直接将备份的目录修改为数据库工作目录）。更甚，通过两次mv命令就可瞬间完成恢复。可以按照时间点恢复。以上的好处，对于以前的软件来说，是很好的方式。但是对于现如今的很多场景，已经不好用了，因为：
服务需要停机：n个服务器肯定无法做到了。然后，以前我们的停机冷备是在凌晨没有人使用的时候进行，但是现在很多的互联网应用已经是面向全球了，所以，任何时候都是有人在使用的。数据丢失：如果不采取措施，那么在完成了数据恢复后，备份时间点到还原时间内的数据会丢失。传统的做法，是冷备还原以后，通过数据库日志手动恢复数据。比如通过 redo日志，恢复是极大的体力活，错误率高，恢复时间长。冷备是全量备份：全量备份会造成磁盘空间浪费，以及容量不足的问题，只能通过将备份拷贝到其他移动设备上解决。所以，整个备份过程的时间很长。如何权衡冷备的利弊，是每个业务需要考虑的。目前不是很推荐这种方式，当然还是要根据自身需求进行选择
1.2 双机热备
双机热备(局域网)
热备，和冷备比起来，主要的差别是
不用停机，一边备份一边提供服务。但还原的时候还是需要停机的。由于我们讨论的是和存储相关的，所以不将共享磁盘的方式看作双机热备。相当于
1主1从，主节点对外提供服务，从节点作为backup。通过一些手段将数据从主节点同步到从节点，当故障发生时，将从节点设置为工作节点。
数据同步的方式可以是偏软件层面，也可以是偏硬件层面的。
偏软件层面的，比如mysql的
master/slave方式，通过同步binlog的方式；sqlserver的订阅复制方式。偏硬件层面，通过扇区和磁盘的拦截等镜像技术，将数据拷贝到另外的磁盘。
偏硬件的方式，也被叫做
数据级灾备；偏软件的，被叫做
应用级灾备。后面谈得更多的是应用级灾备。
1.3 双机互备
双机互备
本质上还是Active/Standby，只是互为主从而已。双机互备
并不能工作于同一个业务，只是在服务器角度来看，更好的压榨了可用的资源。比如，两个业务分别有库A和B，通过两个机器P和Q进行部署。
那么对于A业务，P主Q从，对于B业务，Q主P从。整体上看起来是两个机器互为主备。
这种架构下，读写分离是很好的，单写多读，减少冲突又提高了效率。其他的高可用方案还可以参考各类数据库的多种部署模式，
比如mysql的主从、双主多从、MHA；
redis 的主从，哨兵，cluster 等等
1.4同城双活
同城双活(外网IP通信)
前面的几种方案，基本都是在一个局域网内进行的。业务发展到后面，有了同城多活的方案。和前面比起来，
不信任的粒度从机器转为了机房。
这种方案可以解决某个IDC机房整体挂掉的情况（停电，断网等）。
同城双活其实和前文提到的双机热备没有本质的区别，只是“距离”更远了，基本上还是一样（同城专线网速还是很快的）。双机热备提供了灾备能力，双机互备避免了过多的资源浪费。
在程序代码的辅助下，有的业务还可以做到真正的双活，即同一个业务，双主，同时提供读写，只要处理好冲突的问题即可。需要注意的是，
并不是所有的业务都能做到。业界更多采用的是
两地三中心的做法。远端的备份机房能更大的提供灾备能力，能更好的抵抗地震，恐袭等情况。双活的机器必须部署到同城，距离更远的城市作为灾备机房。
灾备机房是不对外提供服务的，只作为备份使用，发生故障了才切流量到灾备机房；或者是只作为数据备份。
原因主要在于：距离太远，网络延迟太大。
编辑
1.4.1 两地三中心
如上图，用户流量通过负载均衡，将服务A的流量发送到IDC1，服务器集A；将服务B的流量发送到IDC2，服务器B；同时，服务器集a和b分别从A和B进行同城专线的数据同步，并且通过长距离的异地专线往IDC3进行同步。当任何一个IDC当机时，将所有流量切到同城的另一个IDC机房，完成了failover。
当城市1发生大面积故障时，比如发生地震导致IDC1和2同时停止工作，则数据在IDC3得以保全。同时，如果负载均衡仍然有效，也可以将流量全部转发到IDC3中。不过，此时IDC3机房的距离非常远，网络延迟变得很严重，通常用户的体验的会受到严重影响的。
编辑
1.4.2 两地三中心主从模式
上图是一种基于Master-Slave模式的两地三中心示意图。
城市1中的两个机房作为1主1从，异地机房作为从。
也可以采用同城双主+keepalived+vip的方式，或者MHA的方式进行failover。但城市2不能（最好不要）被选择为Master。
1.5异地双活
异地双活(外网IP通信)
同城双活可以应对大部分的灾备情况，但是碰到大面积停电，或者自然灾害的时候，服务依然会中断。
对上面的两地三中心进行改造，在异地也部署前端入口节点和应用，在城市1停止服务后将流量切到城市2，可以在降低用户体验的情况下，进行降级。但用户的体验下降程度非常大。所以大多数的互联网公司采用了异地双活的方案。
简单的异地双活示意图
编辑
上图是一个简单的异地双活的示意图。
流量经过LB后分发到两个城市的服务器集群中，服务器集群只连接本地的数据库集群，只有当本地的所有数据库集群均不能访问，才failover到异地的数据库集群中。
在这种方式下，由于异地网络问题，双向同步需要花费更多的时间。更长的同步时间将会导致更加严重的吞吐量下降，或者出现数据冲突的情况。吞吐量和冲突是两个对立的问题，你需要在其中进行权衡。
例如，
为了解决冲突，引入分布式锁/分布式事务；
为了解决达到更高的吞吐量，利用中间状态、错误重试等手段，达到最终一致性；降低冲突，将数据进行恰当的sharding，尽可能在一个节点中完成整个事务。
示例：饿了么服务器架构
编辑
对于个别一致性要求很高的应用，我们提供了一种强一致的方案（Global Zone），Globa Zone是一种跨机房的读写分离机制，所有的写操作被定向到一个 Master 机房进行，以保证一致性，读操作可以在每个机房的 Slave库执行，也可以 bind 到 Master 机房进行，这一切都基于我们的数据库访问层（DAL）完成，业务基本无感知。
——《饿了么异地多活技术实现（一）总体介绍》
也就是说，在这个区域是不能进行双活的。采用主从而不是双写，自然解决了冲突的问题。
实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。
但其实双活只是一个临时的步骤，最终的目的是切换到多活。因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。
编辑
1.6 异地多活
编辑
异地多活
根据异地双活的思路，我们可以画出异地多活的一种示意图。每个节点的出度和入度都是4，在这种情况下，任何节点下线都不会对业务有影响。但是，考虑到距离的问题，一次写操作将带来更大的时间开销。时间开销除了影响用户体验以外，还带来了更多的数据冲突。在严重的数据冲突下，使用分布式锁的代价也更大。这将导致系统的复杂度上升，吞吐量下降。所以上图的方案是无法使用的。
回忆一下我们在解决网状网络拓扑的时候是怎么优化的？引入中间节点，将网状改为星状：
应对机房级别的故障呢？
没错，就是冗余。
多活的优势在于，可以任意扩展机房「就近」部署。任意机房发生故障，可以完成快速「切换」，大大提高了系统的可用性。
