阿里云数据库已连续多年稳定支撑天猫双11，历经极端流量场景淬炼。除了保障稳定顺滑的基本盘，今年大促期间数据库通过全面云原生化，大幅提升用户体验，让技术帮助业务产生更有价值的消费者体验，持续通过技术创新赋能用户，引领技术发展路径。

双11已圆满落幕，但技术的探索，仍未止步。“阿里云数据库” 公众号特此推出《好科技的新起点——2021双11阿里云数据库技术揭秘》系列干货文章，为你讲述年度“技术大考”背后的故事，敬请关注！

双十一回顾

从平台到商家，再从物流到客户手中，云数据库RDS支撑着双11集团电商的在线业务。RDS首次对集团核心业务进行国产化技术演进试点，具备x86等同性能并兼顾稳定性。针对大促态瞬间大量流量请求场景，内核通过分库分表级别的多点写、热点更新优化、Statement Queue及慢SQL限流等深度内核优化，同时搭配资源独共享混部调度能力，使张北单元大促成本下降30%+，绿色低碳稳定的轻松应对逐年递增的流量洪峰。

RDS集团业务支撑

2019年，集团上云战役开始；到目前为止，集团交易相关RDS已经实现100%云化。当然，上云的背后离不开RDS的针对大B客户上云的后台技术支撑。在资源充足的情况下，通过系统优化一键上云成功率已达到99%。同时，新开深圳、德国、美东等物理Region支持全球集团业务。对于阿里技术团队来说，每年最闪亮的时候就是双11；很多人最感兴趣的是阿里如何做到顺滑的应对这种类似DDOS的洪峰流量的。下面我为大家一一揭秘业务玩法。

大促态集团异地多活

每年双十一的前几周，对于RDS团队来说，最迫切的事情是需要进行大促新单元建站。受资源交付影响，今年时间压缩得比较紧张，相当于三天就需要搞定整个核心集群的建站工作，为业务分流压测做准备。相比去年的人海战术，今年通过RDS自研的内部运维系统督威，快速完成了建站、全网扩容、调参以及巡检一致性校验等相关的工作，为业务分流压测提供足够的时间来保证稳定。

异地多活可以根据用户的流量Region来识别在任意单元进行交易，在大促态时可以做到各单元自闭，同时提供写能力。这样能充分的分担峰值流量，提供更稳定的服务。

核心交易集群的实例日常态有两套独立的三节点集群，他们之间通过DTS进行双向复制。在大促态需要再增加一套三节点集群，这样基于单元能分担更多的读写流量，做到单元自闭，各单元可同时读写。大家也许有疑问，同时写会不会产生主键冲突，怎么保证数据不会写错。这里集团RDS用到了DTS的Store和Writer，Writer主要将Store上的日志应用到对应单元去，又通过Store，由Writer反写回去，两套RDS之间数据表用不同的步长，做到防止主键冲突。传统的防循环复制都是通过事务表来实现，而事务表性能表现不佳。通过Thread ID既能实现防循环复制，又能提升性能。

全球只读和异地容灾

为满足用户按地域读流量快读访问的业务场景，RDS提供全球只读实例，异地只读实例作为一个Learner加入到集群中，不参与主实例三节点的选举，只同步数据和提供读流量，复制采用基于Xcluster内核的原生复制来保证一致性。同时为满足RPO=0的容灾能力，单个只读实例提供同AZ两副本，针对RDS实例非健康状态能快速切换来保证高可用，同时也提供机房容灾能力。

内核Xcluster多点写玩法

集团针对库存业务，新增Xcluster内核提供多点写能力，可以保证主备同时可写，且没有锁冲突，能更进一步的利用容灾的备库资源，分担读写性能。该形态相当于在内核层面实现分库的Group级别的单向复制能力，类似MySQL中的Channel通道复制，该功能的好处是可以实行库级别的多点写入，主备同时提供读写能力，各自独立数据通道互不影响，也不会有冲突问题，在满足性能的同时更好的利用了备库，也节约了资源。当然单个节点RDS服务不健康的时候，HA能够快速的Failover过去，并实现故障转移，能提供高可用服务。当然考虑到故障转移流量都路由到一个节点场景，需要也能满足业务需求，是性价比折中的形态。

底座ARM国产化试点

在2020年的双十一中，我们的ARM国产化主要是MySQL+Ext4文件系统。今年我们在性能上做了更进一步的突破。

大家都知道普通的MySQL记录写入是过程是MySQL->OS->文件系统->写磁盘。由于数据库底层用的是分布式存储，而底层存储可以提供标准的POSIX给客户端，因此我们在这方面做了很多性能优化的工作。

今年ARM MySQL国产化通过内核态改到用户态这样的改造，MySQL直接对接底层文件系统POSIX协议提升效率。

在完成上述改造以后，ARM节点部署在线上核心链路上并承担复制流量。 

绿色低碳

在全球倡导绿色低碳的同时，作为技术人，我们用技术来响应全球的号召，使今年的双十一张北单元大促成本下降30%+，在稳定性兼顾的同时做到绿色低碳。

RDS资源调度新创独共享混部

每年双十一核心集群会有独立部署要求，当性能出现临近点扩容时，就会造成资源浪费。今年新创的独共享混部能力，将核心集群的实例和其他长尾实例混部，实现资源整合。张北混部单元今年全面采用这项技术，节省CPU核心数量4.5万个；结合交易业务云盘化，张北单元整体大促成本下降 34.5%。在每个Node上，ECS主要分为几个资源模块。首先是主机预留，用于系统和对应管控组件，预留之外的都作为资源池给RDS使用，可分配独享实例（相当于进行绑核独享），也可以分配共享实例（相当于独享和预留之外的核数用于共享使用）。这里CgroupController除了需要能够为独享实例绑定CPU核心以外，还需要维护共享实例的CPU资源池。

CgroupController会记录当前节点上独享CPU和共享CPU的核心分布，当节点上的独享实例发生变化时，动态调整Node上共享Pod的可用的CPU列表。例如，当前Node节点预留CPU:[0-1]，调度了一个独享实例占用CPU:[2-3]，CgroupController会计算当前Node节点上的共享CPU=总的CPU-Node预留-独享CPU，并将共享Pod全部绑定到共享CPU核心上。当再调度一个独享pod，CgroupController会更新共享CPU核心，并刷新主机上所有共享POD绑定的CPU核心。

传统的服务器部署MySQL实例有上限，RDS通过调整部署策略进行了突破，如独共享混布，神龙ECS挂盘上限提升，调整IO策略等提升机器密度。通过技术手段节省一半的机头数来部署小规格实例，进一步的提升部署密度，节约大促资源。

业务属性反亲和灵活调度

RDS提供更丰富的资源调度打散策略能力，满足按照业务自定义属性实现打散，进一步提升灵活调度能力。举一个场景，在今年双11前，集团的核心数据库都在云上，但是集团对于不同的业务的数据库有着不同的调度需求，例如交易库必须独占，库存的数据库必须单机两实例。面对这个业务需求场景的时候，按照以往的调度逻辑，都是在集群资源池中来找最优解，这个逻辑肯定无法解决集团的业务调度需求，RDS针对这种场景在业务和资源调度层面增加反亲和性资源调度标识，可以根据业务场景需求来实现单机业务属性的灵活资源调度部署。

RDS内核特性

如何实现RPO=0？

阿里巴巴集团电商全部使用的是RDS三节点企业版，包括主节点（Leader）、备节点（Follower）、日志节点（Logger），通过Paxos协议做到RPO等于0。主要有几个特性: 

• Leader会把待提交的事务传输到其他节点，当达到多数派后在Leader节点上做事务提交；
  
• 当Leader Crash的时候，新的Leader节点会通过自己本地的日志+其他节点日志补全日志并回放完成后，会接受新的事务；
  
• 日志节点仅Binlog日志和一些基础的数据字典信息，这样做的好处是既能满足Paxos协议的多数派，又能节省成本，和MySQL的MGR形成差异化。
  

 

如何跟踪识别限流？

今年的双11，RDS内核做了深度优化,特别是分库分表级别的多点写、Statement Queue及慢SQL限流这块。针对业务系统大促态等特别业务场景，RDS在运行时短时间内突然收到大量的高资源占用的查询请求(例如慢SQL或者OLAP类请求或者极高并发的burst流量),将会造成此时间段内RDS内部的线程池资源被耗尽而无法对其他请求进行服务,从而使得整体性能急剧下降,对业务造成巨大影响，整个过程如下：

RDS内核采用的线程池模型，当新Query需要获取内核CPU资源时首先获取线程资源, 进而由操作系统内核调度获取CPU资源，而高消耗资源SQL的存在会导致新的SQL获取到的CPU时间片少同时线程过多会导致难以获取到CPU资源。

如上图, 一个Work线程会同步等待Innodb的读写结果, 因此在Query IO时间内, 线程资源被当前Query占据。Worker线程数量限制为Thread_pool_size *Thread_pool_oversubscribe, 当有大量Slow Query到来占据线程池资源, 则后续请求无法进去Worker被执行(或者进入线程池后因为IO资源被Slow Query占用而导致IO 等待, 进而恶化线程池资源地释放)。

为减轻Slow Query造成的负面影响,内核基于Statement Digest实现SQB的慢查询检测和限流功能，RDS管控进行了新的内核小版本发布，集团RDS实例全部升级到该版本，实现了100%实例覆盖，进一步的提升性能和RDS稳定性。

Slow Query Blocker分为两个子模块: 慢查询模式匹配过滤模块和检测模块。

匹配过滤模块将根据历史上已发现的Slow Query模式列表, 对匹配上列表中任意模式且并发度达到设定并发度上线的的当前Query语句进行已定义的应对动作。

检测模块分为两个部分：

在普通SQL语句执行之后, 判断其是否是慢查询, 是则插入到慢查询模式列表中根据既定的Slow Query检测策略, 周期性检测Threadpool，测算运行Thread当前执行的Query语句是否超时(Slow Query)。 如果是, 则将当前Slow Query的模式记录到模式列表*过滤模块使用. 根据自定义的Slow Query类型, 还可以自定义该类型Slow Query对应的限流动作，该动作将在限流模块检测到匹配的Query后执行。

内核开启SQB限流功能后，能看到以下现象，对于业务正常的SQL是不受影响的，能正常的请求并获取结果，而不会因为SlowQuery导致的线程池耗尽导致不可服务，进一步提升RDS的稳定性，最大限度的减少用户业务的影响。

未来展望

目前各大云厂商都在进行RDS IPV6技术演进，我们也在快速迭代中，接下来集团部分业务会切到双栈模式。同时，我们也在推进RDS国产化，目前已有部分集团电商交易业务国产化试点。在资源调度方面我们也在探索和推进大混部形态，更进一步的降低大促成本。