简介：异地多活，顾名思义就是散布在异地多个站点同时对外提供服务，与传统灾备最次要的区别是“多活”里所有站点都是同时在对外提供服务的。在业务一直复杂化和容灾要求一直严格化的明天，如何实现云原生的异地多活解决方案，成为了中大型企业不得不面对的挑战。在第十一届中国数据库技术大会（DTCC2020）上，阿里云高级数据库专家张鑫就为大家分享了阿里云云原生异地多活解决方案。

嘉宾介绍：

张鑫（花名：六金），阿里云高级数据库专家，之前次要作为 DBA 反对阿里巴巴外部包含交易、广告等在内的外围零碎，近两年转战专有云市场，面向大型政企客户提供数据库解决方案。

本次分享将次要分为三个方面：

1. 容灾架构剖析
2. 阿里云异地多活解决方案
3. 异地多活客户案例

一、容灾架构剖析

容灾必要性

异地多活自身是从容灾登程的，因而首先介绍一下容灾的必要性。生产零碎可能会遇到三类故障，第一个是主机级故障，如单点负载过高、数据损坏等；第二类是机房级故障，如供电故障、机房网络故障等；第三类是地区级故障，如自然灾害等。对于上述三类故障而言，显然是地区级故障影响面最大，但产生概率最低，但对于主机级故障而言，却并不一定产生概率低且影响面小。阿里巴巴对于本身多年来的故障类型做了梳理，发现随着当初业务零碎复杂度的减少，单点故障也可能会造成全局影响，而且当复杂度达到肯定水平时，如果产生这种单点故障，排查和复原都会十分艰难，因而容灾能力成为了企业信息化建设的必选项。

容灾行业剖析

从行业剖析来看，容灾的市场还是比拟可观的。依据权威报告预测：在 2020 年寰球容灾市场份额将达到 115.9 亿美元，并且客户群体十分宽泛，比方政府、金融、能源、互联网、通信等，基本上只有有信息化零碎就有容灾需要。阿里云目前领有十万家企业用户和四十万个数据库实例，这些都须要容灾能力保障。而在国家层面，也具备严格的合规要求，尤其是当初大型的政企客户都需参照《信息系统容灾复原标准》GB/T 20988 进行容灾建设。

容灾架构演进

容灾架构的演进次要分成几个阶段。同城容灾最为简略，即在同一个地区内有一个 IDC 并部署了业务，容灾时再部署一个机房备份零碎和数据库，在两头实现异步或者同步的数据同步，业务流量集中在一边，另外一边只做灾备。起初逐步演进出了同城双活，其借用了同城内两个数据中心天文间隔比拟近，网络提早较短的劣势，能够将业务部署到两端，因为物理间隔较短，提早等问题都能够承受。再往后就是异地双活，即两点三核心以及其衍生出的两地四核心等，次要就是在同城双活的根底之上再减少一个灾备核心，这个灾备核心常态下是不接管流量的，只有产生地区级故障时才会切换。

传统的容灾计划

从新梳理一下传统的容灾计划，对于同城容灾或者同城双活而言，劣势在于部署简略，并且接入老本非常低；毛病在于仅提供同城爱护，在 GB/T 20988 中只能达到 1 级能力，因而对于大型客户而言，无奈抉择该计划。对于异地冷备而言，劣势同样在于部署简略，对业务侵入比拟少，并且异地部署的灾备能力相对而言会高一些，可能达到 2 到 5 级；毛病在于冷备单元冗余老本较高，造成肯定的资源节约，此外因为灾备单元长年不接流量，因而真正产生故障的时候切换是否可用是一个未知数。对于两地三核心而言，其实就是同城双活和异地冷备两种计划的联合，其劣势就是上述两个计划的劣势，毛病则是冷备核心老本节约和地区级故障产生时不敢进行切换。

二、阿里云异地多活解决方案

阿里云异地多活架构

如上图所示的是阿里云异地多活整体架构。实际上，异地多活的实质是通过对业务做自顶向下的流量隔离来实现的。阿里云将整个异地多活架构分为三层，第一层是接入层，实现异地双活首先须要为业务制订一个分流策略，如依照地区或用户维度调配流量，一旦定义好分流策略，即可在接入层实现流量拆分，属于本单元的流量能够持续向下透传执行，如果不属于则会将其转入正确的单元。第二层是服务层，就是对外提供服务的业务零碎，针对于提供能力的不同划分为了单元化服务、中心化服务和一般服务三种类型。第三层是数据层，这一层所须要解决的是数据库所须要具备的双向跨域同步能力、防循环能力，并且须要保障切流时的数据品质。

阿里云针对 OLTP 和 OLAP 两种业务场景对于多活架构计划进行了细化，接下来一一介绍。

OLTP 业务多活架构

针对于 OLTP 业务，阿里云提供了一套相应的多活架构，其中蕴含了几个要害因素。第一，多活配置，次要通过 MSHA 进行一站式多活配置，其负责制订流量划分策略、决定哪些数据库须要进行多活。第二，多活流量管制，次要依据既定规定通过 MSFE 进行分流，其负责流量辨认、流量散发以及流量校对。第三，多活数据同步，次要是通过 DTS 实现，DTS 自身是数据同步工具，其针对多活场景减少了很多新性能，如防循环、网络优化和切流联动等。第四，多活容灾切换，也是通过 MSHA 实现，次要负责将规格下推到各层，并对多活切换之前的状态进行全局查看。第五，多活场景运维，通过 DMS 实现，多活场景下实现 DDL 变更和数据运维存在双写问题，并存在同步提早的可能，因而执行 DDL 和 DML 变更的策略是不同的，DMS 针对于多活场景进行了能力适配。

OLAP 业务多活架构

OLAP 业务多活架构与 OLTP 区别不大，因素也根本一样，惟一不同在于在 OLTP 业务多活架构中在底层实现了双向的数据同步，在 OLAP 业务多活架构中，则不倡议做这样的工作。次要有两个起因，其一，跨地区数据同步的带宽老本十分高，如果 OLTP 曾经将数据同步了一份，那么尽量抉择在云内同步，而不是 OLAP 同步；其次，还须要保证数据一致性，在 OLTP 上同步了一次，如果在 OLAP 上还须要同步一次，那么保证数据一致性就会比拟艰难。因而，阿里云倡议不在 OLAP 上做数据同步，而应该全副在 OLTP 上做，并且在云内能够实现数据同步能力的补齐。

双活典型架构：双 Region 四 AZ

上图所示的是双活典型架构，分为两个 Region，每个 Region 外面各有两个 AZ，首先具备 AZ 级别的容灾能力，如果真的产生了地区级故障，再将 Region 级别的容灾能力用起来。在这个架构下，MSFE 以及具体业务零碎等是跨 AZ 部署的，在云内具备 AZ 级高可用。数据库在 AZ1 和 AZ2、AZ3 和 AZ4 能够进行主备部署，底层通过 DTS 实现双向同步。数据是四份正本冗余，业务冗余达到 200%，每个 AZ 冗余达到 50%，但真正承接流量时可实现每个 AZ 只有 25%，业务能够自行调配。对于计划外的切换而言，能够达到分钟级 RTO。

多活中不同的服务类型

后面提到服务层分为三种服务类型，第一种是单元化服务，这是在多活架构下次要面向的服务类型，比方淘宝买家的信息批改就是典型的单元化服务，其依据买家的用户 ID 进行流量分流，在这个维度下，能够实现单元内关闭调用，不依赖于对端数据，而底层的数据同步只是在数据切换时确保对端数据是残缺的，可能将数据补齐的，这样切换之后可能让业务间接运行。第二种是中心化服务，次要面向全局配置或者业务具备强核心读写要求的场景，如库存扣减，不容许在多个中央同时扣减同个库存，这种场景肯定会拜访核心数据库，底层通过单向同步来同步数据，这样的服务提供的并不是多活能力，而是容灾能力。第三种是一般服务，所针对的是如果业务依照某一个维度进行了流量划分，那么一些耦合的边缘服务可能无奈依照雷同维度进行划分，这类业务可能会抉择一般服务，比方淘宝交易依照买家 ID 进行划分，那么卖家就无奈依照这一维度进行划分。一般服务可能容忍同步提早，也就是最终统一，然而无奈承受拜访提早，因而次要面向读服务，不倡议写场景应用。

跨云数据同步

上述三种服务类型在底层的数据同步形式不同，因而给出了两种跨云数据同步形式。第一种是 COPY 类型的数据同步形式，次要面向中心化服务和一般服务，数据是单向同步的，单元只可读不可写，同步工作配置通过白名单 +DDL 放行形式实现。第二种是 UNIT 类型的数据同步形式，次要面向单元化服务和一般服务，数据是双向同步的，各单元均可读写，此时就须要通过事务表等解决防循环问题，并且通过全局 Sequence 防止抵触。

防循环 &Sequence

阿里云 POLARDB 和 RDS 数据库等针对于防循环和 Sequence 两个能力进行了实现。在防循环局部，次要提供了两种形式，第一种是事务表形式，也就是业务在写入数据库的时候，即事务提交实现，生成 Binlog，Binlog 被 DTS 拿走并解析实现后会发现向指标单元 DB 写入的时候会在事务表外面产生一个自定义记录，这样一来在单元外面落地的事务实际上除了原始业务逻辑之外还会多一个小 Event。通过指标端的 DTS 解析之后就会发现 Binlog 外面还多了一个事务操作，就会晓得这个操作是来自于 DTS 的，而不是来自于业务零碎的，因而能够将该操作过滤掉，进而搁置数据循环。第二种是通过 THREAD_ID 的形式，这是 AliSQL 内核定制的优化性能，将原生 MySQL 内核的 THREAD_ID 从 8 字节改到了 5 字节，因而业务生成连贯只能是 0x00000 到 0xFFFFF 之间，而高位则留给 DTS 连贯应用，这样核心 DB 就可能区别两类连贯，Binlog 会记录所有的 THREAD_ID，因而 DTS 也可能很清晰地解析进去操作来自于业务还是 DTS，如果来自业务就同步过来，如果来自 DTS 就中断掉，从而达到防循环的性能。第一种形式对业务具备肯定的侵入性，第二种则是齐全原生的能力，对用户或者内核没有太大影响。

对于 Sequence 性能而言，其实就是在两边同时写入数据，须要保证数据不能抵触。因而，阿里云针对于 POLARDB- X 做了全局惟一 Sequence 的能力，在原生的 DDL 下面减少了标识去管制以后单元个数以及每个单元的 Index。基于这种形式创立进去的表，以内步长为 10 万，单元数为 2 举例，产生后果如上图所示，从而达到全局 Sequence 的能力。

多活场景数据保护

在多活场景下，和原生最大的区别就是不须要关注可用性，然而却多了数据品质的问题，该问题在单数据中心场景下可能不容易产生，然而在多活场景下因为业务须要双写，因而容易呈现数据品质的抵触问题。归根结底，所有的数据品质问题都是因为数据双写导致的，因而须要针对于这种场景制订肯定的保护措施。阿里云制订了三个维度的单元保护措施，第一个是日常态，针对接入层、应用层和数据层提供相应的办法多写操作的多活分流规定进行路由逻辑校验，如果非本单元流量，则在接入层和应用层将流量转走，但如果在数据层，则间接阻塞掉。第二个是变更态，次要针对数据运维变更，比方批量数据勘误，阿里云提供了事先检查和预先补充的能力，在 DMS 下面针对于多活场景下的数据变更工作提前查看变更状况，如果同步提早很大则会被阻塞掉，升高了数据双写的概率，同时在变更前和变更后通过查看保持数据的统一。第三个是切流态，是在数据多活切流过程中做的爱护策略，包含了相对禁写、提早禁写、前镜像匹配同步以及提早查看等性能。

多活切流流程

在多活切流时，首先会关上前镜像匹配性能。个别认为，在多活场景下业务写入的数据比同步过去的数据更重要，因而须要保障业务写入的数据不被同步的数据笼罩掉，所以如果切流过程中，数据同步有提早，为了不笼罩掉业务数据，则须要将 Binlog 里背后镜像拿进去拼到 SQL 外面去执行。前镜像匹配性能开启之后会将新的流量散发规定在各层进行下发，在规定下发实现之后会开启相对禁写的动作，在此过程中，所有参加切流的用户流量是无奈执行的。在禁写过程中首先须要判断三层规定是否全副收敛胜利，其次还须要判断每层内各个节点的规定是否收敛胜利，最终目标是让所有服务器上的规定保持一致，这样能力保障不呈现双写。上述条件满足之后，解除相对禁写，开启提早禁写，这一点可由用户配置。当数据同步实现之后，解除禁写和前镜像匹配，切流过程至此实现。

异地多活价值总结

简略总结下异地多活的价值。首先，多活自身是做容灾的，然而当初来看异地多活曾经不像是传统容灾那样搁置一个灾备单元了。当初业务即容灾，业务零碎和容灾零碎严密地连贯到了一起。其次，业务连续性有了保障，为业务提供了高可用能力。第三，为业务的高速倒退提供了撑持，在多活场景下划分了很多原子单元，能够依据原子单元正当配比相干资源，达到最优成果，最终具备跨地区的程度扩大能力。第四，流量无效隔离，基于阿里云的异地多活解决方案能够非常灵活地调配流量，能够依照不同维度设置规格，也能够依照不同的权重配比设置，实现流量大小的灵便调配，并可实现在最小单元内进行危险可控的技术试验。第五，降本增效，传统容灾计划无奈冲破 200% 的冗余老本问题，而通过三活、四活的计划能够实现冗余老本小于 200%。

用户自行施行异地多活的难点

用户自行施行异地多活所需面对很多难点，如流量治理难度高、数据同步策略简单、容灾切换数据品质保障难，以及多数据中心对立管控难度大等，这也是阿里巴巴将异地多活能力积淀为产品级解决方案的推动力。基于阿里云的异地多活计划，用户只须要关系如何对流量进行宰割即可。

阿里云云原生计划劣势

目前可能实现产品级异地多活能力的厂商极少，阿里云通过 8 年的积攒和积淀，在异地多活的云原生计划上具备诸多劣势。

三、异地多活客户案例

客户案例 - 某税务外围零碎

某税务外围零碎的异地多活计划也是依照三层架构实现的，在接入层，反对依照两个维度流量拆分，即省份和自然人档案号。在服务层利用 CSB 产品实现一般服务的跨云调用。在数据层，针对不同服务类型施行不同容灾级别的数据同步。最终实现了两个维度的多活，秒级切换能力，达到了国标 6 级成果，因为基于两单元接流，因而在老本上具备劣势，并且具备灰度放量能力。

客户案例 - 某运营商客服零碎

某运营商客服零碎实现了按省份分流能力，即依照 DNS 的地区分流接入南北两个核心，接入层依照路由规定进行判断和纠错，在业务层对于客户原有零碎进行了适配革新，实现了双核心的服务同步。在数据层，则通过 POLARDB- X 和 DTS 实现双向数据同步。最终使得该运营商客服零碎的多个业务按地区多活分流，在屡次容灾演练中，能够实现秒级切换，并保障了数据 0 失落。此外，因为常态由两个单元承载业务流量，因而老本也有所升高。

作者：stromal
原文链接
本文为阿里云原创内容，未经容许不得转载