蚂蚁金服天街：蚂蚁双11大促OceanBase核心技术全解析

演讲嘉宾简介：田启杰（花名：天街）

现任蚂蚁金服高级技术专家，2012年加入OceanBase 团队，曾五次做为OceanBase负责人承担双11大促保障工做，致力于OceanBase 提供高可用/高性能/低成本的数据库服务，在数据库相关技术及业务大促保障上有多年的沉淀和积累。

本次视频精彩回顾，戳这里！如下内容根据演讲嘉宾视频分享以及PPT整理而成。

本次的分享主要围绕如下五个方面：

1. 2018 OceanBase大促概述
2. 百万支付&OceanBase2.0
3. 容器化
4. 平台智能化
5. 将来发展规划

1、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个机房来进行服务，因此它在可预见的范围内是不会成为瓶颈的。四小时建站，能够在四小时以内在任意一个站点把支付宝的任意的服务都搬到上面去，包括数据，代理数据也能够迁出去。

2、百万支付&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运行存在单点依赖，但如今将单点依赖上面的数据所有打散到不少的应用服务器上面就不会存在单点宕掉带来的故障影响。第三是灰度能力，在应用变动或者版本更新时，灰度能力能够作到只针对部分分片进行变动，影响范围变得更小。资源的规格和负载均衡主要是原来满负载的库经过分区的方式分红了统一的小块，针对每一个小块分配统一的资源。负载均衡最优的实践就是平铺，把压力平铺到全部服务器上。

3、容器化

为何要进行容器化？

资源过剩。大促态下须要节省成本，成本体如今两点。首先，减小应用服务器的数量，第二，下降持有服务器的时长。这两个加起来就是大促成本，那如何解决资源总数的问题。第一种思路是性能优化，OceanBase2.0采起的就是性能优化，它在不提高机器数量的状况下提高单机服务能力高达百分之五十。第二点是下降持有时长，高峰期前缩容，高峰期扩容，或者抢占高峰期资源。下降持有时长理念的背后核心思想就是调度，把核心数据库快速地调度到有资源的地方。这也是容器化的目的，容器化屏蔽了底层资源的差别，它隔离了底层资源，保证想要的资源。平常的服务器的资源每每都是过剩的。由于在每一阶段对资源的诉求是不同的，不一样业务的资源利用率是不一样的。如何把总体资源进行统一是容器化要解决的问题。

资源负载。前面已提到了有长尾，碎片等问题。

资源规格。由于访问带来的资源分为绝对资源和相对资源。业务有CPU和Disk存储，CPU对不一样业务的资源的差别很大，这是绝对资源的差别。相对资源差别是指一些业务消耗了CPU和Disk，另一些业务只消耗了CPU，CPU和Disk相对的差别就是相对资源差别。两种资源都是资源规格要统一的问题。

机型和部署。每一年双11采用的服务器机型都是不同的，服务器的资源异构的程度很大。须要把异构机型的能力发挥出来，这是容器化要解决的前提。每一年大促时，部署复杂度体现为环境的复杂度，好比自建的机房，这些底层的部署差别反映到DB端带来的问题是随着业务的发展，对容灾要求和查验能力是存在差别的。不一样部署须要有统一的解决方案。

容器化三个核心点

容器化是必要的。容器化中最关键的三点分别是规格归一，资源隔离，抢占和多纬调度。

规格统一。规格统一最重要的是分配，如UID，业务的分配。在进业务端入口时分红资源进口分流，不会称为访问的热点。同时作业务改造，读请求较高的时候加读库能够下降压力。经过资源规格归一以后，定义出的无数规格能够知足蚂蚁全部资源的诉求。

资源隔离，抢占。经过对资源进行分级变体，高分级业务能够去抢占低分级业务的资源，以保证稳定性。把资源放到对支付体验有影响的资源上面。

多维调度。多维调度的范围比较大，这里的资源是广义的资源，从业务入口一直到真实落到DB的过程当中以不一样的资源维度进行调度。

OceanBase大促容器化架构

IaaS层。包括金融云，阿里云以及混合云，在任何一个云上都要构建容器化的架构。

调度层。一层是统一sigma调度，主要作统一资源规划，生命周期的管理和资源弹性的规划。二层是 kipp 和 OceanBase的调度，按照不一样租户的画像信息，得出调度策略是平铺，抢占仍是资源亲和。单机不超过 1% 的容灾，经过资源亲和，把一笔支付链路上所可以通过全部的应用和 DB调度在一个机器上，经过一个亲和性标签放在一块儿，大大下降宕机的影响面。右边是调度管控。

价值贡献。顶层是容器化达到的价值贡献，最大的贡献是经过均衡资源利用率达到了价值翻倍。存区 & 存储就近是指让存储节点和计算节点二者离得最近。

4、平台智能化

为何要作平台智能化？

大促常态化。目前支付宝一年下来大促有十几回，平均一月一次。大促的稳定性要求很高，流程性很强，那怎么保证每月大促的平稳？传统方法作简单的扩容，成本浪费。因此要将大促的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事件是十分有帮助的。

平台智能化会提供索引绑定，更便捷地利用平台智能化解决故障。在后期也会覆盖更多能力。

5、将来发展规划

资源。资源是大促的核心价值，要用最小的资源解决用户最大的问题。首先经过统一调度，把DB，用户服务器，各类机型，资源池所有打通，这样技术可发挥的空间更大。第二，混合部署。统一部署以后会分池分布，分类混布。最后，分时复用。混布和分时复用的效率体现很明显，在不须要作大促处理的时候能够节省资源开销，2019年会对此作很大变化。

自治。智能化的最终目标就是自治，这也是如今的发展大趋势。分为 OceanBase 内核的自治和平台化的自治。平台化的自治分为三块,自愈，自调优和自驾驶。自愈就是自我修复，分为硬件类和软件类的故障修复。自调优就是Auto tuning，多是输出运行的问题。自驾驶是扩缩容，租户容量等平常的问题不须要人为参与。

点击阅读更多查看更多详情