蚂蚁金服双11大促全面揭秘：深入洞察OceanBase云平台

摘要：本文重点分享了在双11背景下，OceanBase云平台所遇到的挑战，介绍了针对实时监控和规模运维两个方面云平台所提供的应对策略，并详细解释了需要做哪些设计才可以解决这些挑战？本文从开发者视角，带大家了解构建大规模分布式系统要关注的事情。

演讲嘉宾简介：

张松树（花名：笑言）：现任蚂蚁金服 OceanBase 团队技术专家，2014 年加入阿里巴巴，曾是阿里云 GTS 产品 Founder，从事领域涉及分布式事务、中间件高可用，致力于分布式系统稳定性的建设工作，目前主要负责 OceanBase 云平台的建设。

本次直播视频精彩回顾，戳这里！https://tech.antfin.com/activities/41/review/54

以下内容根据演讲嘉宾视频分享以及PPT整理而成。

https://tech.antfin.com/activities/41/review

本次的分享主要围绕以下四个方面：

一、双11带来的挑战

二、实时监控技术点剖析

三、极致运维技术点剖析

四、OceanBase云平台

一、双11带来的挑战

刚刚过去的2018年双11是阿里双11的第十个年头。从2009年开始，当时一天的营业额还不到1个亿，但是到了2012年，营业额就已经增长到了191亿。在这三年当中，除了逐年成倍增长的销售数字，另外比较重要的事情就是OceanBase诞生了。2014年，OceanBase开始应用于支付宝的核心交易系统，当时OceanBase的版本是0.5版本，一个开源版本，大家最开始了解OceanBase就是从0.5版本开始的。到了2015年，将近1000亿的日营收，蚂蚁交易支付链路百分之百的流量都已经切到OceanBase上了。2016年双11，支付宝的每秒支付峰值创造了12万笔/秒的世界记录。全世界比较大的交易系统有Visa和Master。Visa的支付峰值大概是5万笔/秒，Master比Visa略少一些，所以12万笔/秒是非常有纪念意义的。2017年双11，诞生了数据库处理峰值4200万/秒世界纪录，2018年，OceanBase在存储成本以及性能方面有了重大突破。

下面的漫画生动地描绘了双11前阿里技术人员的工作状态。在双11将要开始的一段时间，对于技术人员心脏的挑战是非常大的。普遍来说，每年双11从零点时刻开始，交易曲线会在很短的时间内冲到峰值，在峰值处很平稳的运行10分钟左右，然后再掉下来。大家可以思考一下，为什么会存在那段10分钟左右的平稳期？这是因为系统容量不足以承载瞬时流入的海量请求，这时系统会采取一些自我保护手段来保证系统不被压垮，这也是分布式高可用的一些特征，做互联网应用的人会比较熟悉这一点。这些策略包括限流、预付、当天无法退货等，这是都是为了保证系统的高可用而采取的措施。但是没有用户请求被限流，才是最理想的购物体验，这要求我们的技术人员需要通过技术手段来不断提升用户的购物体验。

双11具体会给OceanBase带来什么挑战呢？

首先看系统高可用，简单来说，高可用就是能够时时刻刻提供一个持续稳定的服务。如果只有几百几千人使用系统，高可用是很容易实现的。但是对于数十亿用户同时并发请求的情况，如何维持如此大规模分布式系统的高可用是一个非常挑战技术深度的事情。来看OceanBase，目前OceanBase有数万个的服务节点，这些服务节点分布在阿里巴巴不同的数据中心。服务器部署在不同的地域会衍生出一系列问题，比如不同地域之间存在网络延迟，北京到上海，大概有30-50毫秒的延迟。那么我们的数据库需要尽可能的保证事务操作不跨地域，以保证数据库服务稳定。

还有实时计算和监控能力的问题，前面所提到的，4200万条SQL在同一秒产生，每条SQL背后有大量、多维度的监控数据，监控信息散落到分布式系统中，要给不同业务视角的同学提供满足业务需求的数据，需要把这些散落在数万个服务节点上数据快速发现、聚合、实时计算并且展示出来。这也是极具挑战的。

另外，怎么能做到全方位的安全？数据安全是系统的底线，无论是数据库服务，还是数据库平台都会将数据安全作为系统建设的基本原则。

还有，如何做到极低的资源占用？在做分布式系统时，需要考虑资源问题。由于几万台服务器本身的成本是非常庞大的数字，我们的用户在进行技术选型的时候，成本是很重要的考虑因素，所以将系统资源发挥到它的极限对于工程师来说是极具挑战的。

最后一个挑战是系统要做到可定制可扩展。做业务系统时所能提供的功能非常有限，无法预设到百分之百，也不可能匹配到所有用户的需求，只能尽可能的把系统做到用户可自定义，站在用户的视角来，把他们的问题解决掉。对于OceanBase来说，可定制可扩展是非常重要的问题，它需要给每一个用户提供专属的数据库操作体验，用户可以通过接口或者服务，通过数据库云平台做一些定制化的操作。

二、实时监控技术点剖析

一条SQL的一生

一个数据库能够正确的执行SQL是最基本的功能。而对于OCP来说，这只是开始。分布式系统与单机系统最大的区别是分布式系统由多个服务器组成，那么数据究竟在哪个服务器节点上？一条SQL由哪台服务器承担执行任务？如果发生了问题，应该到哪一台机器说查找数据，并解决问题？这些都是OCP关注的问题。OCP对租户级和会话级的监控数据进行采集，包括监控项，等待事件和锁事件。采集完之后对采集的数据从不同的视角进行聚合，给不同的业务人员提供满足他们视角的视图。之后对数据进行分析，包括分析SQL性能，执行路径等等，给用户提供实际的建议。根据预设规则或者自定义规则，实时告警。这些流程是整个分布式系统能够提供更好更稳定服务的必备环节。

实时监控-海量数据处理

下图左边是蜂窝状的数据库服务器，它会分布在全国各地多个机房内。那么该如何集中化处理这些数据？最简单的方法是把他们采集到集中式的数据库里面，但随之而来的问题就是不同地方的数据所经历的延时不一样。数据采集到数据库里面后，对于这些不是同一个时间段的数据如何提供统一的视图？数据进行集中处理后，要做相应的加工，如果加工的链路足够的长，足够的耗时，那么数据实时性就会遇到问题。而且对于数据所给出的建议功效也会大打折扣。所以需要采用高质量的算法和并行计算的策略解决这个问题。同样，通过聚合的链路把数据进行分类，如建议事件，警告事件，普通事件等。采用不同事件处理流程解决不同的数据。

实时监控-监控信息

每一条SQL都会产生N个监控项，比如，4200万条SQL背后的数据量是N*4200万监控信息。在这种量级下，分布式系统的开发人员重点关注哪些问题？如下图，在系统级别下包括集群，实例，主机，事务，IO，锁和临界区等指标。在SQL级别下由延时，返回行，CPU时间占用，逻辑读行数，物理读的行数，内部等待和外部等待花费的时间等。如此多的数据就仅仅只是一条SQL下来所产生的数据。

作为分布式系统的构建者，面对如此多的数据，该采用什么存储方式？通常来说，主要有两种存储模型，一种是窄表模型，另一种是宽表模型。对于窄表来说，一行信息里面有两个或三个字段，一条信息所包含的属性比较少。宽表则相反，一行里有比较多的属性，少则几十个，多则上百个。窄表典型的代表是HBase，宽表就是MySQL。他们的问题和优缺点也是显而易见的。

比如说要统计一台机器在某一个时间点的所有的信息，要在程序里实现，在窄表模型下想要对这些信息做扩展，开发者说需要改代码，而这种操作对于分布式系统构建者是非常不友好的事情。最理想的是通过一条SQL或修者改一个列就可以做到信息扩展，所以宽表模型对于维护成本相对较低。

但是在另外的问题上，宽表模型的扩展性并没有那么好，比如想要加一个属性，可能还需要考虑加到哪张表，字段需要什么描述方式。这时窄表就具备扩展性的优势。在表结构变更时，比如1个TB数据的表，加一个字段是很难想像的。

OceanBase是一款准内存数据库，中间数据保存在内存中，周期性和基线数据做合并，因此DDL不会产生锁表问题；OceanBase采用了高效的压缩算法，尽可能的很好的解决了经济性的问题。同时，使用OceanBase不需要额外部署资源，对于提升构建系统的效率无疑是重大利好。

三、极致运维技术点剖析

近几年分布式系统发展特别快，包括阿里、AWS都已经有了成熟的全链路监控跟踪系统，OCP也一样。

每一条SQL或者事务都会有个全局唯一的Transaction ID，可以帮助DBA和运维人员根据Transaction ID到数据库的服务器中抓日志、查问题；DBA和运维人员还利用OCP上提供的一系列服务做运维相关的工作，包括集群管理、计算逻辑编排、流程控制等。OCP对每一次的操作都会有一个全局的Request ID来全链路跟踪该操作所经过的每一个环节；Transaction ID表现在数据库层面，Request ID表现在平台服务层面，作为开发者，能够结合业务，做完整业务的全链路是我们下一步要关心的事情。

数据库的使用者比较关心的是数据库的增删改查，而对于OCP实现者来说，还需要对数据库进行监控、运维、调度，提供数据服务、数据管理、数据库诊断等。OCP提供了Open-SDK的方式，让每个人都可以根据自己的需求以及喜好来定制自己的数据库。

四、OceanBase云平台

下面看看Oracle云是怎么做的。最底层，Oracle数据库服务跑在云主机上，有可能是公有云（如阿里云，AWS、腾讯云）；可能是专有云，大型的企业用户可能会自建机房，将数据库服务部署在自建机房里；也可能是混合云，将自建机房和公有云做打通，数据在专有云里面，然后管控和服务在公有云上。中间层，Oracle会把数据管理，应用集成等基础的能力包装成服务发布给开发者。最上层，将会有不同的业务视角提供给不同角色。

下图是阿里内部的OCP的构建模式。底层是由物理机，ECS，Docker等组成的基础设施层;上面是OceanBase数据库；OceanBase之上构建了OCP平台以及各类平台服务。OCP从功能上来说包括监控、运维、诊断、资源调度等基础应用，另外还有数据迁移、备份恢复、历史库等数据管理类应用。服务之上，构建了Open-SDK，将服务能力通过SDK的方式发布出去，SDK能够帮助大家跟自己的业务系统做结合。最上面提供了不同的业务视角，比如开发人员会关心一个数据库实例的状态，用户DBA会关注自己的集群运行状态，系统的DBA要从更宏观的层面关心所有系统之间负载是否均衡，稳定性是否好。

现状

下图是目前OceanBase云平台所应用的场景，客户包括蚂蚁金服，网商银行，南京银行，浙商银行等等。右边是阿里巴巴内部应用的场景，OceanBase在集团内得到了广泛的应用。OceanBase是经过了8年的验证磨练出来的成熟的产品。然而云平台成长的时间并不长，还处于初级的阶段。我们的初级目标是系统变得更稳定，功能更友好。对比Oracle，内核研发人员是几千人，但是Oracle公司其实有几万人。他们有大量的人都投入到了工具，平台，致力于怎能让数据库从使用的感知更友好，这是我们OceanBase云平台所关注的事情。

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