RDS 5.7三节点企业版在阿里巴巴的应用

  RDS 5.7三节点企业版是阿里自主研发，完全兼容MySQL生态的全球级分布式强一致的关系型数据库。从2017年开始在集团大规模使用，目前不仅服务了天猫/淘宝核心交易系统，还在蚂蚁，菜鸟，钉钉，盒马，优酷，高德，口碑等阿里子BU大量使用，这篇我们来看看ALISQL金融三节点的具体应用场景。

一.RDS 5.7三节点企业版的核心优势

  上篇我们介绍了RDS 5.7三节点企业版数据一致性解决方案，这个章节我先对RDS 5.7三节点企业版的核心优势做下简单汇总。

1.数据强一致能力

  RDS 5.7三节点企业版在AliSQL的基础上集成了X-Paxos。借助X-Paxos的分布式一致性算法，RDS 5.7三节点企业版从功能层面可以彻底解决数据质量问题，让RDS 5.7三节点企业版从AliSQL时代的数据一致性问题中彻底走了出来，从借助生态解决一致性问题，升级到产品内部一体化方式来彻底解决。

2.RDS 5.7三节点企业版的性能优化

我们都知道强一致一定带来性能的下降，我们来看在RDS 5.7三节点企业版上我们做了哪些优化，来提升吞吐和性能。

1).一体化的日志设计

  RDS 5.7三节点企业版的Consensus日志是合并了原有的binlog和relay_log， 但是保留了原有的MySQL binlog的事务日志格式。一体化日志带来的好处首先是减少一份日志的写入；其次扫描日志可以做到顺序IO，这个点尤其对Paxos算法下日志的检索和获取效率是一个提升。

2).异步事务提交

  首先X-Paxos完全基于多线程实现，可以在单个分区Paxos中完全的使用多线程的能力，所有的任务都有通用的worker来运行，消除了CPU的瓶颈。在这个基础上，我们在服务层对事务流程进行拆分（处理请求→等待同步→事务提交），不同阶段由线程池的不同线程完成。借助X-Paxos的多线程模式以及服务层的异步化改造，系统吞吐有很大的提升。尤其在跨域或者跨国场景下，巨大的网络延迟使得线程池成为一种瓶颈：实际运行中会发现线程池绝大部分线程在等待日志跨单元同步回包，服务端就没有足够的线程去处理客户请求。

3).Batching &Pipelining

  X-Paxos针对高延迟网络做了大量的协议优化尝试和测试，并结合学术界现有的理论成果通过合理的Batching和Pipelining，设计并实现了一整套自适应的针对高延迟高吞吐和低延迟高吞吐网络的通信模式，极大的提升了X-Paxos的性能。Pipeling的引入，需要解决日志的乱序问题，特别是在异地场景下，window加大，加大了乱序的概率。X-Paxos实现了一个高效的乱序处理模块，可以对底层日志实现屏蔽乱序问题，实现高效的乱序日志存储。
如上几个点的优化，保证了RDS 5.7三节点企业版在同城多机房部署或者跨域多单元部署时，写入性能和单节点模式（非强一致）无大幅度劣化。如上功能的提供以及性能优化让RDS 5.7三节点企业版真正能解决一致性问题，同时通过近两年在集团的推广使用也验证了RDS 5.7三节点企业版的可靠性和完备性。

3.多种角色及动态变更

  除了一致性的解决外，RDS 5.7三节点企业版还借助了X-Paxos强大的生态功能，增加了RDS 5.7三节点企业版的灵活性，体现在如下几个点上：
  1).友好的管控操作：支持在线添加&删除节点，支持在线转让leader；
  2).策略化多数派和权重化选主：可以让业务根据自己的部署特点自行配置；
  3).节点角色定制化：经典的multi-paxos实现中，一般每个节点都包含了Proposer/Accepter/Learner三种功能，每一个节点都是全功能节点。RDS 5.7三节点企业版支持三种功能的独立配置，将Paxos算法中节点的三个功能进行了剥离和重组，形成了多种不同角色的节点。具体如下：

  4).SDK模式:我们把learner角色封装成一个SDK，通过SDK，可以快速实现RDS 5.7三节点企业版和下游各系统的对接，闭环形成完整的生态。比如：基于订阅者功能，我们可以实现日志的实时备份、下游的增量实时订阅消费等功能。如下是一个线上集群的真实运行案例。

二.常见的RDS 5.7三节点企业版的部署模式

  我们现在知道RDS 5.7三节点企业版不仅做了高性能的强一致，而且能为业务提供灵活丰富的部署模式。下面我们来看下在阿里应用的几种部署模式。

1.同城跨机房模式

部署模式图

特点

1).机房级别容灾，数据零丢失，10秒级别的容灾能力；
2).部署采用两数据副本，一日志节点（无数据，同时最低配置）。相比主备方案成本增加很有限；
3).备份接入SDK后，RPO<1秒。

这个模式是集团最常用的模式，对该模式进行各种扩展，可以到下面几种模式（扩展的模式都具备了备份RPO<1秒的能力）

2.跨域高性能模式

部署模式图

特点

1).机房级别容灾能力的基础上，具备跨域接流能力。
2).高性能：该模式是在同城达到强同步，对于写业务性能相对跨域强同步是有很大提升的。
3).模式扩展能力：在该模式下，华南region异常时，华南region的业务会读站华北；
   如果想要同城容灾能力，可以在华南region再加一个learner节点，添加这个节点对业务写性能无任何影响。

3.跨域强同步模式

部署模式图

特点

1).真正的跨域强一致能力：任意城市不可用，不影响集群的可用性，数据零丢失。
2).灵活的切换策略：可设置同城节点，跨域节点的切换优先级。
3).灵活的伸缩能力：该部署模式可以在面临大促等需求时，可以动态将跨域强同步模式切换到跨域高性能模式：在保证机房级别容灾的基础上，获取更高性能。

业务应用实践案例

  我们看到阿里内部常用的几种部署模式后，接下来我们看下RDS 5.7三节点企业版结合具体业务的应用扩展案例。我们最常用的结构是同城跨机房部署模式，这种模式用最小成本给业务带来了强一致，刚开始只在金融、结算等对一致性要求极高的业务线落地，随着推广和产品的完备，该部署模式是同城容灾的默认部署模式。
  在之前的单元化、区域化等项目中，单元之间同步都依赖DTS来完成。在有了RDS 5.7三节点企业版之后，鉴于RDS 5.7三节点企业版在跨单元的性能优化，对于跨域同步需求，RDS 5.7三节点企业版内部就可以直接完成。借助多角色能力，优酷通过在香港单元动态扩展一个Leaner角色的节点实现“优酷出海”；同时中心化单元架构也都演进了RDS 5.7三节点企业版的跨域高性能模式。接下来我们来介绍一个跨域高性能模式下的一个极致优化案例。

1.交易库存大促方案

  交易库存作为交易链路的核心系统之一，承载着淘宝、天猫、航旅、大麦等业务的库存扣减。对阿里单元化了解的同学基本都清楚，交易单元化是从买家维度进行的拆分，使得交易在多个单元都可以为买家提供服务。而库存由于跟买家和卖家都相关，采用的是中心模式的单元化架构。所以在数据库架构上选择了RDS 5.7三节点企业版的跨域高性能模式。下面我们看下在面临双十一极限流量挑战时，我们的应对策略。

1).一键切换级联复制模式

  我们先看下库存的日常级联模式，如下图：

  在这个模式下，leader需要给5个节点发日志，在性能压测阶段，我们发现leader的TPS到6W时，热缓冲区锁的争抢导致出现性能瓶颈。单元同步改到中心follower节点后，leader节点的RT大幅下降。如下是大促级联模式图以及压测结果对比。

2).弱一致模式

  通过该参数weak_consensus_mode可以打开RDS 5.7三节点企业版同步的弱一致模式，打开后，事务提交无需再等待达成多数派。当然打开后，数据一致性会回退到主备模式，我们目前就只在大促开始高峰期开启。高峰期过后，这个参数就会恢复。
3).热点更新以及热点更新下的同步性能优化
  热点更新原本就是数据库的一个难题，受制于引擎内部的行锁竞争，性能吞吐一直很难提升上去。RDS 5.7三节点企业版面对跨域场景下的长传网络更加是雪上加霜，提交的时间变长，事务占据行锁的时间也显著增加。为了解决这个问题，RDS 5.7三节点企业版在原AliSQL的热点功能上优化了复制，使得保证数据强一致的情况下，热点更新性能提升200倍。

  如上图所示，RDS 5.7三节点企业版针对热点行更新的基本思路是合并多个事务对同一行的更新。为了让批量的更新事务能够同时进行提交，RDS 5.7三节点企业版增加了一种新的行锁类型——热点行锁。热点行锁下，热点更新的事务之间是相容的。 RDS 5.7三节点企业版为了保证数据的一致性，对同一批的热点更新事务日志打上特殊标志， RDS 5.7三节点企业版会根据这些标志将这一整批事务的日志组成一个单独的网络包进行集群间的数据同步，保证这些事务是原子的提交/回滚。除此之外为了提升日志回放的效率，RDS 5.7三节点企业版将每个批次事务中对于热点行的更新日志也做了合并，保证了库存单元和DTS的延迟。
  经历连续两年双十一的大考，高流量高性能验证了RDS 5.7三节点企业版的稳定性和极致性能。

2.菜鸟电子面单异地容灾方案

  在主备同步时代，我们只需要关注主备数据在主库宕机时的一致性问题。到了DTS链路的单元化架构时，我们的数据一致性问题被放大很多：跨单元的数据一致性如何保证？面对单元化架构的异地容灾，HA应该如何切换？DTS的位点如何联动？我们来看下菜鸟电子面单的异地容灾场景下的解决方案。
  菜鸟电子是菜鸟网络联合快递公司向商家提供的一种物流面单服务，商家在ISV软件提供商发货时，会通过电子面单获取物流包裹信息，打印后交付快递公司揽收派送。电子面单打单量巨大，而且服务可用性要求非常高（5个9），一旦服务异常，大量商家无法发货，严重影响物流时效，甚至带来社会影响。同时电子面单对数据一致性要求很高：电子面单的一个大核心功能是给物流商提供唯一的面单序列号，这个序列号作用于物流的整个生命周期，而如果出现序列号错乱可能会导致包裹无法揽收，物流详情错乱等业务影响。综上我们把这里的业务需求转换为技术要求：数据强一致和跨域容灾能力。同时从资源成本考虑，业务不仅是异地部署，是要达到双活。
  因此在数据库层面我们采用了RDS 5.7三节点企业版跨域强同步模式，在这个模式下，应用层节点写leader，leader写入后强同步到异地follower节点，保证了多地域的数据强一致；对于跨域写leader这块，业务通过定制化连接池、Batch SQL提交等技术，把异地网络耗时降到最低，保证了异地双活链路的服务可用性。应用读服务采用读本地策略。另外从成本考虑，华东Follower节点我们也调整为Log节点。具体的业务部署图如下

接下来我们重点看下网络耗时减小的优化方案：

1).事务专用连接池

  系统原本使用的数据库中间件对连接池的管理上使用的是auto_commit是true，这样每次事务执行时，都会存在auto_commit设置以及复位带来的DB交互。考虑到跨域网络延迟加大，业务层面自行维护了一个事务专用连接池，让这些连接的auto_commit属性持续保持是false。同时在事务访问上，我们结合了特有的hint（COMMIT_ON_SUCCESSROLLBACK_ON_FAIL），减少单独一次的commit或者rollback带来的网络交互。这样在事务层面把网络耗时减到最小。

2)事务内多条SQL请求批量合并

  默认情况下，MySQL JDBC驱动不支持BATCH，当业务层发起多条SQL请求时，JDBC驱动会将所有语句拆散，串行发送到服务端执行。该种模式在跨地域写的场景下，每一条SQL执行，都会带来40ms跨城耗时叠加。考虑到该点，我们在业务层对JDBC驱动配置进行了调整，利用rewriteBatchedStatements + allowMultiQueries，最终将事务中所有多条写SQL语句一次性批量发送到DB服务端执行，去除了原有串行执行的网络开销。
通过在业务层面的两个优化，我们把原本270ms的跨域事务写耗时降低到了70ms，与中心交互次数从原有6次降低到1次。
这样我们在菜鸟电子面单业务上，结合RDS 5.7三节点企业版以及业务优化最终做到了：
  1).容灾演练:同城容灾时，会根据我们的权重配置，优先切换到同城（华北）的follower节点。当华北地域有异常时，剩余华南华东节点会重新选主，切主到华南follower，由于节点数据保持强一致性同步，该部署架构下，切主无数据质量风险。实际演练数据是23s完成中心leader 切主到异地follower节点。
  2).双活性能方面:经过如上的应用层网络耗时的优化，电子面单整体集群采用华北中心-华南单元双活分流，其中华南集群承担超过20%取号流量，由于启用了双活RT优化，华南单元取号接口RT稳定保持在90ms左右，与华北中心RT差距<30ms，系统成功率持续大于99%。
  如上介绍了RDS 5.7三节点企业版在双十一大促库存场景下的极致优化案例，以及菜鸟电子面单业务跨域强一致、跨域容灾架构下的极致优化方案。这些案例都是极致情况下的极致优化，对于大部分业务来说，RDS 5.7三节点企业版 常见的部署模式完全可以适用。

综述

  该专题系列围绕着“去IOE”后，阿里巴巴数据库在数据一致性上的解决方案。在MySQL主备模式下，我们借助一些功能补丁以及周边生态的建设来尽量保证单机，主备集群，单元化架构下的数据一致性问题。到了RDS 5.7三节点企业版时代，我们借助他强大的一致性功能以及极致的性能优化，做到了完全为数据一致性负责。同时借助RDS 5.7三节点企业版灵活的部署模式，让阿里的数据库架构在RDS 5.7三节点企业版时代都有了新的升级。随着RDS 5.7三节点企业版成为金融三节点（5.7）产品正式上云，期待可以为更多的用户带来更多的技术红利。RDS 5.7三节点企业版作为一个新的数据库产品，大家有任何问题，都欢迎通过云上数据库专家服务联系我们。