关于后端:高可用解决方案同城双活异地双活异地多活怎么实现

后盾服务能够划分为两类，有状态和无状态。高可用对于无状态的利用来说是比较简单的，无状态的利用，只须要通过 F5 或者任何代理的形式就能够很好的解决。后文形容的次要是针对有状态的服务进行剖析。服务端进行状态保护次要是通过磁盘或内存进行保留，比方 MySQL 数据库，redis 等内存数据库。除了这两种类型的保护形式，还有 jvm 的内存的状态维持，但 jvm 的状态生命周期通常很短。

高可用的一些解决方案

高可用，从倒退来看，大抵通过了这几个过程：

• 冷备
• 双机热备
• 同城双活
• 异地双活
• 异地多活

在聊异地多活的时候，还是先看一些其余的计划，这有利于咱们了解很多设计的原因。

冷备

冷备，通过进行数据库对外服务的能力，通过文件拷贝的形式将数据疾速进行备份归档的操作形式。简而言之，冷备，就是复制粘贴，在 linux 上通过 cp 命令就能够很快实现。能够通过人为操作，或者定时脚本进行。有如下益处：

• 简略
• 疾速备份（绝对于其余备份形式）
• 疾速复原。只须要将备份文件拷贝回工作目录即实现复原过程（亦或者批改数据库的配置，间接将备份的目录批改为数据库工作目录）。更甚，通过两次 mv 命令就可霎时实现复原。
• 能够依照工夫点复原。比方，几天前产生的拼多多优惠券破绽被人刷掉很多钱，能够依据前一个工夫点进行还原，“挽回损失”。

以上的益处，对于以前的软件来说，是很好的形式。然而对于现如今的很多场景，曾经不好用了，因为：

• 服务须要停机。n 个 9 必定无奈做到了。而后，以前咱们的停机冷备是在凌晨没有人应用的时候进行，然而当初很多的互联网利用曾经是面向寰球了，所以，任何时候都是有人在应用的。
• 数据失落。如果不采取措施，那么在实现了数据恢复后，备份工夫点到还原工夫内的数据会失落。传统的做法，是冷备还原当前，通过数据库日志手动复原数据。比方通过 redo 日志，更甚者，我还已经通过业务日志去手动回放申请复原数据。复原是极大的体力活，错误率高，复原工夫长。
• 冷备是全量备份。全量备份会造成磁盘空间节约，以及容量有余的问题，只能通过将备份拷贝到其余挪动设施上解决。所以，整个备份过程的工夫其实更长了。设想一下每天拷贝几个 T 的数据到移动硬盘上，须要多少移动硬盘和工夫。并且，全量备份是无奈定制化的，比方只备份某一些表，是无奈做到的。

如何衡量冷备的利弊，是每个业务须要思考的。

双机热备

热备，和冷备比起来，次要的差异是不必停机，一边备份一边提供服务。但还原的时候还是须要停机的。因为咱们探讨的是和存储相干的，所以不将共享磁盘的形式看作双机热备。

Active/Standby 模式

相当于 1 主 1 从，主节点对外提供服务，从节点作为 backup。通过一些伎俩将数据从主节点同步到从节点，当故障产生时，将从节点设置为工作节点。数据同步的形式能够是偏软件层面，也能够是偏硬件层面的。

偏软件层面的，比方 mysql 的 master/slave 形式，通过同步 binlog 的形式；sqlserver 的订阅复制形式。

偏硬件层面，通过扇区和磁盘的拦挡等镜像技术，将数据拷贝到另外的磁盘。偏硬件的形式，也被叫做数据级灾备；偏软件的，被叫做利用级灾备。后文谈得更多的是利用级灾备。

双机互备

实质上还是 Active/Standby，只是互为主从而已。双机互备并不能工作于同一个业务，只是在服务器角度来看，更好的压迫了可用的资源。比方，两个业务别离有库 A 和 B，通过两个机器 P 和 Q 进行部署。那么对于 A 业务，P 主 Q 从，对于 B 业务，Q 主 P 从。整体上看起来是两个机器互为主备。这种架构下，读写拆散是很好的，单写多读，缩小抵触又进步了效率。

其余的高可用计划还能够参考各类数据库的多种部署模式，比方 mysql 的主从、双主多从、MHA；redis 的主从，哨兵，cluster 等等。

同城双活

后面讲到的几种计划，根本都是在一个局域网内进行的。业务倒退到前面，有了同城多活的计划。和后面比起来，不信赖的粒度从机器转为了机房。这种计划能够解决某个 IDC 机房整体挂掉的状况（停电，断网等）。

同城双活其实和前文提到的双机热备没有实质的区别，只是“间隔”更远了，基本上还是一样（同城专线网速还是很快的）。双机热备提供了灾备能力，双机互备防止了过多的资源节约。

在程序代码的辅助下，有的业务还能够做到真正的双活，即同一个业务，双主，同时提供读写，只有解决好抵触的问题即可。须要留神的是，并不是所有的业务都能做到。

业界更多采纳的是两地三核心的做法。远端的备份机房能更大的提供灾备能力，能更好的抵制地震，恐袭等状况。双活的机器必须部署到同城，间隔更远的城市作为灾备机房。灾备机房是不对外提供服务的，只作为备份应用，产生故障了才切流量到灾备机房；或者是只作为数据备份。起因次要在于：间隔太远，网络提早太大。如上图，用户流量通过负载平衡，将服务 A 的流量发送到 IDC1，服务器集 A；将服务 B 的流量发送到 IDC2，服务器 B；同时，服务器集 a 和 b 别离从 A 和 B 进行同城专线的数据同步，并且通过长距离的异地专线往 IDC3 进行同步。当任何一个 IDC 当机时，将所有流量切到同城的另一个 IDC 机房，实现了 failover。当城市 1 产生大面积故障时，比方产生地震导致 IDC1 和 2 同时进行工作，则数据在 IDC3 得以顾全。同时，如果负载平衡依然无效，也能够将流量全副转发到 IDC3 中。不过，此时 IDC3 机房的间隔十分远，网络提早变得很重大，通常用户的体验的会受到重大影响的。上图是一种基于 Master-Slave 模式的两地三核心示意图。城市 1 中的两个机房作为 1 主 1 从，异地机房作为从。也能够采纳同城双主 +keepalived+vip 的形式，或者 MHA 的形式进行 failover。但城市 2 不能（最好不要）被抉择为 Master。

异地双活

同城双活能够应答大部分的灾备状况，然而碰到大面积停电，或者自然灾害的时候，服务仍然会中断。对下面的两地三核心进行革新，在异地也部署前端入口节点和利用，在城市 1 进行服务后将流量切到城市 2，能够在升高用户体验的状况下，进行降级。但用户的体验降落水平十分大。

所以大多数的互联网公司采纳了异地双活的计划。上图是一个简略的异地双活的示意图。流量通过 LB 后散发到两个城市的服务器集群中，服务器集群只连贯本地的数据库集群，只有当本地的所有数据库集群均不能拜访，才 failover 到异地的数据库集群中。

在这种形式下，因为异地网络问题，双向同步须要破费更多的工夫。更长的同步工夫将会导致更加重大的吞吐量降落，或者呈现数据抵触的状况。吞吐量和抵触是两个对抗的问题，你须要在其中进行衡量。例如，为了解决抵触，引入分布式锁 / 分布式事务；为了解决达到更高的吞吐量，利用中间状态、谬误重试等伎俩，达到最终一致性；升高抵触，将数据进行失当的 sharding，尽可能在一个节点中实现整个事务。

对于一些无奈承受最终一致性的业务，饿了么采纳的是下图的形式：对于个别一致性要求很高的利用，咱们提供了一种强统一的计划（Global Zone），Globa Zone 是一种跨机房的读写拆散机制，所有的写操作被定向到一个 Master 机房进行，以保障一致性，读操作能够在每个机房的 Slave 库执行，也能够 bind 到 Master 机房进行，这所有都基于咱们的数据库拜访层（DAL）实现，业务根本无感知。

也就是说，在这个区域是不能进行双活的。采纳主从而不是双写，天然解决了抵触的问题。

实际上，异地双活和异地多活曾经很像了，双活的构造更为简略，所以在程序架构上不必做过多的思考，只须要做传统的限流，failover 等操作即可。但其实双活只是一个长期的步骤，最终的目标是切换到多活。因为双活除了有数据抵触上的问题意外，还无奈进行横向扩大。

异地多活 依据异地双活的思路，咱们能够画出异地多活的一种示意图。每个节点的出度和入度都是 4，在这种状况下，任何节点下线都不会对业务有影响。然而，思考到间隔的问题，一次写操作将带来更大的工夫开销。工夫开销除了影响用户体验以外，还带来了更多的数据抵触。在重大的数据抵触下，应用分布式锁的代价也更大。这将导致系统的复杂度回升，吞吐量降落。所以上图的计划是无奈应用的。

回顾一下咱们在解决网状网络拓扑的时候是怎么优化的？引入两头节点，将网状改为星状：革新为上图后，每个城市下线都不会对数据造成影响。对于原有申请城市的流量，会被从新 LoadBalance 到新的节点（最好是 LB 到最近的城市）。为了解决数据安全的问题，咱们只须要针对核心节点进行解决即可。然而这样，对于核心城市的要求，比其余城市会更高。比方复原速度，备份完整性等，这里临时不开展。咱们先假设核心是齐全平安的。

如果咱们曾经将异地多活的业务部署为上图的构造，很大水平解决了数据到处同步的问题，不过仍然会存在大量的抵触，抵触的状况能够简略认为和双活差不多。那么还有没有更好的形式呢？

回顾一下前文提到的饿了么的 GlobalZone 计划，总体思路就是“去分布式”，也就是说将写的业务放到一个节点的（同城）机器上。阿里是这么思考的：实际上我猜想很多业务也是依照上图去实现的，比方滴滴打车业务这种，所有的业务都是按城市划分开的。用户、车主、目的地，他们的经纬度通常都是在同一个城市的。单个数据中心并不需要和其余数据中心进行数据交互，只有在统计出报表的时候才须要，但报表是不太重视实时性的。那么，在这种状况下，全国的业务其实能够被很好的 sharding 的。

然而对于电商这种简单的场景和业务，依照前文说的形式进行 sharding 曾经无奈满足需要了。因为业务线非常复杂，数据依赖也非常复杂，每个数据中心互相进行数据同步的状况无可避免。淘宝的解决形式和咱们切分微服务的形式有点相似：留神看图中的数据同步箭头。以交易单元为例，属于交易单元的业务数据，将与核心单元进行双向同步；不属于交易单元的业务数据，单向从核心单元同步。核心单元承当了最简单的业务场景，业务单元承当了绝对繁多的场景。对于业务单元，能够进行弹性伸缩和容灾；对于核心单元，扩大能力较差，稳定性要求更高。能够遇见，大部分的故障都会呈现在核心单元。

依照业务进行单元切分，曾经须要对代码和架构进行彻底的革新了（可能这也是为什么阿里要先从双活再切到多活，历时 3 年）。比方，业务拆分，依赖拆分，网状改星状，分布式事务，缓存生效等。除了对于编码的要求很高以外，对测试和运维也有十分大的挑战。如此简单的状况，如何进行自动化笼罩，如何进行演练，如何革新流水线。这种级别的灾备，不是个别公司敢做的，投入产出也不成正比。不过还是能够把这种场景当作咱们的“假想敌”，去思考咱们本人的业务，将来会怎么倒退，须要做到什么级别的灾备。相对而言，饿了么的多活计划可能更适宜大多数的企业。

本文只是通过画图的形式进行了简略的形容，其实异地多活是须要很多很弱小的根底能力的。比方，数据传输，数据校验，数据操作层（简化客户端管制写和同步的过程）等。

起源 | https://blog.dogchao.cn/?p=299