蚂蚁金服双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

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

1、双11带来的挑战

2、实时监控技术点剖析

3、极致运维技术点剖析

4、OceanBase云平台

1、双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来讲，可定制可扩展是很是重要的问题，它须要给每个用户提供专属的数据库操做体验，用户能够经过接口或者服务，经过数据库云平台作一些定制化的操做。

2、实时监控技术点剖析

一条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不须要额外部署资源，对于提高构建系统的效率无疑是重大利好。

3、极致运维技术点剖析

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

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

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

4、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云平台所关注的事情。

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