掘金 后端 ( ) • 2021-12-06 12:02

简介:从绿色低碳到硬核科技,看RDS如何用绿色科技助力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国产化,目前已有部分集团电商交易业务国产化试点。在资源调度方面我们也在探索和推进大混部形态,更进一步的降低大促成本。

原文链接

本文为阿里云原创内容,未经允许不得转载。