蚂蚁金服天街：蚂蚁双11大促OceanBase核心技术全解析
qingtianweichong 2019-06-30
演讲嘉宾简介：田启杰（花名：天街）
现任蚂蚁金服高级技术专家，2012年加入OceanBase 团队，曾五次作为OceanBase负责人承担双11大促保障工作，致力于OceanBase 提供高可用/高性能/低成本的数据库服务，在数据库相关技术及业务大促保障上有多年的沉淀和积累。
本次视频精彩回顾，戳这里！以下内容根据演讲嘉宾视频分享以及PPT整理而成。
本次的分享主要围绕以下五个方面：
- 2018 OceanBase大促概述
- 百万支付&OceanBase2.0
- 容器化
- 平台智能化
- 未来发展规划
一、2018 OceanBase大促概述
对于OceanBase数据库而言，在大促面前需要面对来自容量、稳定、成本、效率、压测和弹性这6个方面的挑战：
容量。如何支撑全国人民一起去买东西是一个难题。容量方面主要可以分为两个点，数据库单机性能和某一个集群的容量，而这两点无论在哪一个层面上都要考虑大促的需求。单机性能指的是在大促压力下，数据库单机能否满足某个业务的需求；而集群容量则需要综合考虑应用、网络、机房的组合，争取使成本降到最低。
稳定。稳定大于一切！高峰期的任何抖动都可能对用户产生很大影响。
成本。在平时状态下，每秒大约有8000人正在完成支付，但双11需要支撑40多万人并发进行支付，因此服务能力可能需要增长五六十倍，那么，机器是否需要增加五六十倍呢？因此，需要思考能否使用尽量少的机器来节省成本。除了大促商品优惠的成本，技术人员所需要考虑的最大成本就是机器成本。
效率。前几年可能在每年的六月份就要开始准备双11，那时所投入的人力成本很大。而如果在一个月的时间内完成大促准备，就需要高效率。
压测。如果大促的流量要翻五六十倍，那么为了保证增加新机器时不出问题，并且成本可控，就需要尽可能模拟真实业务的工作压力，把真实情况下的热点对数据库的冲击在压测环境下模拟出来。
弹性。弹性指的是将所有服务，包括从前端入口、应用服务器、数据库以及网络，通通从原本的服务站点很快地迁移到一个全新的站点上面去的能力。此外，还需要在迁移的过程中将原本一秒八千多的支付能力拓展到四十多万的支付能力。
如果能够合理应对以上6点挑战，那么就能够在技术角度完美地支持和应对双11大促。
OceanBase弹性化体系
基础设施。基础设施中包括网络、存储、内核以及机房。网络指的是在云环境下的XGW虚拟的网络和VPC的网络。存储投在物理机或者ECS上面，高性能的ECS怎么和DB的容器进行结合。操作系统的能力上从内核来看OceanBase是AIO，DIO，CPU的隔离以及CPU的share。机房的Mancore互联，可以认为它是一个网络的创新,实际上是让三个机房两两互联，两个机房之间任意一条网络断掉，都能保证至少有两个机房是能够工作的。
基础架构。基础架构统一的基座是容器和资源，比如阿里云公共的服务器。再往上是OceanBase本身在大促体系下的一些关键的属性，比如租户的拆百和分区，独立异构的FO。FO是指拉起新的独立的没有任何运行关联的库让业务恢复起来。第四个是三地五中心。然后是多副本架构，其中有提供具有读写能力的副本，提供只读的副本以及只投票的副本，这种不同的副本类型结合OceanBase的弹性，再搭配进行工作。
能力沉淀。OceanBase做的一些服务站，比方说OCP，以及其他一些模块。可以认为将大促中提到的6个点的通用能力给抽象出来，然后和日常服务相结合，沉淀出通用的能力。
大促服务。无损压测指的是做一些模拟压测时保证对线上业务没有任何影响，统一的思想就是隔离。隔离时要及时把压测的流量熔断掉，比如说把DB的水位，应用服务器的访问的ID做一些预测。如果任务出来会挂掉的话，就要进行压测，或者把资源在真实的在线库和压测库之间做一个快速的迁移。极致弹性是指将全国100个UID中任意一个UID都可以弹到任意一个机构里面去。一个瓶颈可能是体现在机房上，与机房的用地，电力等不可突破的因素有关。如果可以做到极致性，便可以体现一点，就是可以将100个UID在大促时摊到100个不同的城市，从100个不同城市挑选100个机房来进行服务，所以它在可预见的范围内是不会成为瓶颈的。四小时建站，可以在四小时之内在任意一个站点把支付宝的任意的服务都搬到上面去，包括数据，代理数据也可以迁出去。
OceanBase弹性化体系
基础设施。基础设施中包括网络、存储、内核以及机房。网络指的是在云环境下的XGW虚拟的网络和VPC的网络。存储投在物理机或者ECS上面，高性能的ECS怎么和DB的容器进行结合。操作系统的能力上从内核来看OceanBase是AIO，DIO，CPU的隔离以及CPU的share。机房的Mancore互联，可以认为它是一个网络的创新,实际上是让三个机房两两互联，两个机房之间任意一条网络断掉，都能保证至少有两个机房是能够工作的。
基础架构。基础架构统一的基座是容器和资源，比如阿里云公共的服务器。再往上是OceanBase本身在大促体系下的一些关键的属性，比如租户的拆百和分区，独立异构的FO。FO是指拉起新的独立的没有任何运行关联的库让业务恢复起来。第四个是三地五中心。然后是多副本架构，其中有提供具有读写能力的副本，提供只读的副本以及只投票的副本，这种不同的副本类型结合OceanBase的弹性，再搭配进行工作。
能力沉淀。OceanBase做的一些服务站，比方说OCP，以及其他一些模块。可以认为将大促中提到的6个点的通用能力给抽象出来，然后和日常服务相结合，沉淀出通用的能力。
大促服务。无损压测指的是做一些模拟压测时保证对线上业务没有任何影响，统一的思想就是隔离。隔离时要及时把压测的流量熔断掉，比如说把DB的水位，应用服务器的访问的ID做一些预测。如果任务出来会挂掉的话，就要进行压测，或者把资源在真实的在线库和压测库之间做一个快速的迁移。极致弹性是指将全国100个UID中任意一个UID都可以弹到任意一个机构里面去。一个瓶颈可能是体现在机房上，与机房的用地，电力等不可突破的因素有关。如果可以做到极致性，便可以体现一点，就是可以将100个UID在大促时摊到100个不同的城市，从100个不同城市挑选100个机房来进行服务，所以它在可预见的范围内是不会成为瓶颈的。四小时建站，可以在四小时之内在任意一个站点把支付宝的任意的服务都搬到上面去，包括数据，代理数据也可以迁出去。
二、百万支付&OceanBase2.0
百万支付目标
下图展示每年双11峰值的能力和成交的笔数，十年来双11峰值的攀升基本上是垂直上涨的曲线。在未来，峰值能力怎么能够不成为支付的瓶颈？比如目前只能支撑50万人同时支付，那该如何打破这个瓶颈？未来可能需要有100万人在每秒一起进行工作。蚂蚁提出了三年战斗百万支付的目标，在高峰期，一秒钟进行100万的支付，同时一天可以支撑1亿订单。
百万支付瓶颈
支撑百万支付目标要做什么事情呢？从整个链路上来说的话，要看哪一份资源在扩展性上有瓶颈。扩展性上的瓶颈可以认为谁带数据状态，谁就是最难扩展的。实际上是想利用的服务器是无状态的，因为它没有自己一个真实的业务属性。那可以认为应用服务器的瓶颈就在于它所在的机房的瓶颈，所以服务器是不会成为百万支付的瓶颈的。那么瓶颈只可能在数据库上，因为一个人的数据只有一份，只能用在应用服务器，由于应用服务器的服务能力是有上限的，如何打破上限？下面分别从性能和资源角度进行了讨论。
性能。最小的数据分片性能已经达到了单机瓶颈，目前生成环境中最厉害的应用服务器大概是96C左右，实际上，2012年是32C，2016到了64C,到2018年已经用了96C。可以看到32C到96C花了6年的时间，但是峰值从2012到现在已经翻了二十多倍。单纯依靠硬件的叠加是不可取的，需要靠OceanBase支撑的数据库的性能。
资源。资源异构和负载均衡。假设大促与十条链路有关系，十条链路的压力是以金字塔尖倒置递减的，入口处压力最大，即创建交易的压力最大。再往下是支付环节，其中有花呗，余额宝，银行卡等，随着链路的延伸会有分力的作用，如花呗和银行卡是使用独立的资源进行部署，对于DB的压力是下降的。不同的库对应了不同链路，访问的压力是递减的。随着链路的延申，资源异构的差异化很大，意味着应用服务器的水位就会时高时低。在百万支付场景下，百分之九十的资源都用来交易支付，剩下的资源非常少，如何打破的这个瓶颈，也是另一个要解决的问题。
OceanBase2.0理念
OceanBase2.0的一个理念是针对性的解决数据分片的单机性能瓶颈。下图中上面有一个DB,假设它服务所有的UID是00的支付宝用户，00中有三张表，其中四有颜色，它们代表事务跨越三张表，三张表里面任意一个人交易的时候所用到的数据在不同表中使用了相同的颜色。如果在交易时00库扛不住了，传统的方案落到DB就是分库分表。新起一套库，这套库是原来容量的四倍，同时把原来三张表按照相同的规则分到独立的库中，再通过ElasticRule告诉底层路由从不同库中读取数据。但是分库分表有几个不友好的点，首先业务感知到了,所以要追溯到数据源。其次，应用统计上链路都是独立的，无法共享。还有数据库拆分之后，但是缩容时是不是要保留四个最小规格，这便是长期存在现象的尾巴。最后，之前配套的工具都要进行改变。OceanBase2.0采取的方案是分区（Partition），数据库的数目并没有增加，但是可以按照一定规则，将满足相同分区规则的数据聚合在同一个机器上。这能够很大程度上提高单机的性能，解决未来支付能力上升的瓶颈问题。
OceanBase2.0架构
那么OceanBase2.0架构下的路由是怎么工作的？一个服务器过来发给SQL，SQL传给中间件，中间件提供路由功能，它把分库分区表的规则做好，比如表级别的规则，DB级别的规则，弹性的规则以及分区的规则。中间件把分片的信息发送到OBClient, OBClient会制造一个生成列partition_id，发送给OBerver，由做一个分区裁剪。分区裁剪会精确地找到分片所在的DB上的应用服务器在哪里。生成列与业务方绑定在一起，从业务日常表的列中选取两位最适合的做分片，孕育出来生成列的规则应用在表级别，全栈的表都采用这样的规则。另外，分区规则的维护是一个固化的规则，OceanBase通过约束能力（constraint）提供分区裁剪能力，这时不要求中间件有分区裁剪能力，只要把约束定义好，把OceanBase调到最佳就可以了。
百万战略基石
OceanBase2.0实现了弹性伸缩，也做到了业务无感和无损。业务无感是说DB做扩容时不需要感知到扩容。DB做扩容或者弹性时没有业务失败，叫无损。无损更多的是与OceanBase内核三节点的能力和做事务的能力绑定在一起。极致高可用指的是要做到五个九，折合下来一年不可用时间是52分钟。首先通过故障隔离，任何单点故障之间是不会影响到另外一台服务器的。单点消除是说原本DB运行存在单点依赖，但现在将单点依赖上面的数据全部打散到很多的应用服务器上面就不会存在单点宕掉带来的故障影响。第三是灰度能力，在应用变更或者版本更新时，灰度能力可以做到只针对部分分片进行变更，影响范围变得更小。资源的规格和负载均衡主要是原来满负载的库通过分区的方式分成了统一的小块，针对每个小块分配统一的资源。负载均衡最优的实践就是平铺，把压力平铺到所有服务器上。
三、容器化
为什么要进行容器化？
资源过剩。大促态下需要节省成本，成本体现在两点。首先，减少应用服务器的数量，第二，降低持有服务器的时长。这两个加起来就是大促成本，那如何解决资源总数的问题。第一种思路是性能优化，OceanBase2.0采取的就是性能优化，它在不提升机器数量的情况下提升单机服务能力高达百分之五十。第二点是降低持有时长，高峰期前缩容，高峰期扩容，或者抢占高峰期资源。降低持有时长理念的背后核心思想就是调度，把核心数据库快速地调度到有资源的地方。这也是容器化的目的，容器化屏蔽了底层资源的差异，它隔离了底层资源，保证想要的资源。日常的服务器的资源往往都是过剩的。因为在每一阶段对资源的诉求是不一样的，不同业务的资源利用率是不同的。如何把整体资源进行统一是容器化要解决的问题。
资源负载。前面已提到了有长尾，碎片等问题。
资源规格。因为访问带来的资源分为绝对资源和相对资源。业务有CPU和Disk存储，CPU对不同业务的资源的差异很大，这是绝对资源的差异。相对资源差异是指一些业务消耗了CPU和Disk，另外一些业务只消耗了CPU，CPU和Disk相对的差异就是相对资源差异。两种资源都是资源规格要统一的问题。
机型和部署。每年双11采用的服务器机型都是不一样的，服务器的资源异构的程度很大。需要把异构机型的能力发挥出来，这是容器化要解决的前提。每年大促时，部署复杂度体现为环境的复杂度，比如自建的机房，这些底层的部署差异反映到DB端带来的问题是随着业务的发展，对容灾要求和查验能力是存在差异的。不同部署需要有统一的解决方案。
容器化三个核心点
容器化是必要的。容器化中最关键的三点分别是规格归一，资源隔离，抢占和多纬调度。
规格统一。规格统一最重要的是分配，如UID，业务的分配。在进业务端入口时分成资源进口分流，不会称为访问的热点。同时做业务改造，读请求较高的时候加读库可以降低压力。通过资源规格归一之后，定义出的无数规格可以满足蚂蚁所有资源的诉求。
资源隔离，抢占。通过对资源进行分级变体，高分级业务可以去抢占低分级业务的资源，以保证稳定性。把资源放到对支付体验有影响的资源上面。
多维调度。多维调度的范围比较大，这里的资源是广义的资源，从业务入口一直到真实落到DB的过程中以不同的资源维度进行调度。
OceanBase大促容器化架构
IaaS层。包括金融云，阿里云以及混合云，在任何一个云上都要构建容器化的架构。
调度层。一层是统一sigma调度，主要做统一资源规划，生命周期的管理和资源弹性的规划。二层是 kipp 和 OceanBase的调度，按照不同租户的画像信息，得出调度策略是平铺，抢占还是资源亲和。单机不超过 1% 的容灾，通过资源亲和，把一笔支付链路上所能够经过所有的应用和 DB调度在一个机器上，通过一个亲和性标签放在一起，大大降低宕机的影响面。右边是调度管控。
价值贡献。顶层是容器化达到的价值贡献，最大的贡献是通过均衡资源利用率达到了价值翻倍。存区 & 存储就近是指让存储节点和计算节点两者离得最近。
四、平台智能化
为什么要做平台智能化？
大促常态化。目前支付宝一年下来大促有十几次，平均一月一次。大促的稳定性要求很高，流程性很强，那怎么保证每个月大促的平稳？传统方法做简单的扩容，成本浪费。所以要将大促的6个点固化，朝智能化方向走。
业务规模爆发。随着业务规模爆发，要解决硬件存在的隐患，为了满足业务的需求，传统方式是行不通的。怎么解决 10w+ 机器操作系统从 6U 升级到 7U？
稳定性。要达到 5 个 9目标，不能依赖于传统平台，只能靠智能平台来做。
OceanBase 大促智能化实践
扩缩容和Rebalance。首先对链路信息和 DB 运行状态进行建模，将业务容量刻画出来，进行水位模拟，可以得出容量图案。通过平台的分析将图案转化成一个一个变更，下发到平台形成变更链表。
SQL 调优。记录每一条 SQL，给出SQL调优的建议。
压测的资源预测和熔断。如果预测到 RT 水位对于业务来说是超时的，就停止自动压测。有助于降低线上的故障率。
OceanBase大促智能化模块
感知。首先捕获线上所有异常，异常是方方面面的，结合画像进行 workload 建模，得出模型,预测。
决策。第一种方法是靠人的经验，形成一个决策树，对每一分支进行分析，往下寻找修复。第二种方法是机器学习，根据一些算法做输入，通过演进和优化不断得出最佳的决策方案。执行器。根据上层信息诊断得出需要执行的方案，比如需要调优，扩容或者其他。对此做好幂等控制和免疫控制。因为有些执行不是无损的，可以实时感知线上链路的变化，做成一个可监控可回复的模块来实现变更的免疫。
SQL自愈案例
SQL故障感知。下图是支付宝网上银行业务量的变化情况。在报警格式下面有三个数字，kpi真实值是180ms,即限制监测到的真实情况，预测值是6ms,即认为应该是业务量长到6ms就可以提供服务的，基线值285us。这三个数字得出之后发现到6ms之后每月提供服务，所以不符合的预期。
故障识别。通过故障根因分析，给出三个规则。第一个是SQL id,就是指SQL有问题。第二个是IO出问题。第三个RPC出问题。通过分析得出概率比较高的问题，认为规则1里的SQL可能是问题所在。
故障恢复的过程。根据SQL id给出诊断建议。诊断建议是全表扫描，提供可选择的索引，这对于突发的SQL事件是十分有帮助的。
平台智能化会提供索引绑定，更便捷地利用平台智能化解决故障。在后期也会覆盖更多能力。
五、未来发展规划
资源。资源是大促的核心价值，要用最小的资源解决用户最大的问题。首先通过统一调度，把DB，用户服务器，各种机型，资源池全部打通，这样技术可发挥的空间更大。第二，混合部署。统一部署之后会分池分布，分类混布。最后，分时复用。混布和分时复用的效率体现很明显，在不需要做大促处理的时候可以节省资源开销，2019年会对此做很大变化。
自治。智能化的最终目标就是自治，这也是现在的发展大趋势。分为 OceanBase 内核的自治和平台化的自治。平台化的自治分为三块,自愈，自调优和自驾驶。自愈就是自我修复，分为硬件类和软件类的故障修复。自调优就是Auto tuning，可能是输出运行的问题。自驾驶是扩缩容，租户容量等日常的问题不需要人为参与。
点击阅读更多查看更多详情
