首发 | OceanBase 2.0 重磅发布，全面下降金融业务向分布式架构转型的技术风险

OB君：9月21日下午，在云栖大会ATEC数字金融架构转型分论坛中，蚂蚁金服OceanBase团队的资深技术专家蒋志勇正式宣布OceanBase 2.0重磅发布，并深刻解读了OceanBase 2.0的产品新特性和重大技术突破点。

OceanBase是一款彻底自主研发的金融级分布式关系数据库，超过100万行的核心代码都由OceanBase团队的同窗一行行敲出来。

从2010年立项到今天，过了8年；在最近4年多时间里，一直服务于金融核心业务。2014年，OceanBase开启了支付宝核心业务去Oracle的进程，在当年的“双十一”，支撑了10%的交易流量；最终在2017年，成功完成支付宝交易、支付、帐务、会员等所有核心业务的去Oracle的工做。这在中国乃至全球都是一个标志性的事件。

对比一下美国的状况，前段时间有报道称亚马逊准备在2020年完全去除对Oracle数据库的依赖，马上引来了Oracle创始人的反击，他表示亚马逊已经尝试过不少次，但从未成功，足以见得去Oracle这件事对于企业而言的难度之大。

一样在2017年，OceanBase和蚂蚁金融科技的其余产品一块儿帮助南京银行创建了互联网金融核心系统。从去年开始截止到今天，OceanBase已经在6家外部金融机构上线，包括商业银行和保险机构。全球前三名的支付平台，两家的核心系统都在使用OceanBase数据库。

为了知足业务快速发展以及持续可用的要求，系统架构从集中式转向分布式是大势所趋。在数据库层面，要相应地从单机数据库转向分布式数据库。

今天，咱们发布OceanBase 2.0版本，这是OceanBase数据库自身发展的里程碑，也是咱们参与金融行业向分布式架构转型的关键一步，用数据库技术创新为业务架构转型奠基基础，解除行业发展的后顾之忧。

在架构转型过程当中，技术决策者每每会碰到三大挑战：

第一大挑战：技术风险

第一个是技术风险，传统单机数据库系统通过几十年的发展，运行在可靠的专用硬件和存储上，在金融行业获得充分锻炼，总体稳定。分布式数据库系统运行在普通商业硬件上，采用廉价存储，运行环境和传统方式有很大差别，保证系统可用性和可靠性的手段也大不相同；同时在某些基本行为方面和传统单机数据库也有差别。好比要获取一个系统一致性快照，对单机数据库是一件很轻松的事情，但在分布式系统中，却没那么容易。若是不能提供一致性快照，业务系统就被迫要作相应的改造和调整，调整就会带来风险。能够说：对于一些基本特性，分布式数据库系统相对于传统数据库的每个行为上的差别都增长了架构转型的不肯定性，颇有可能就是在转型的道路上埋了一个雷。

第二大挑战：迁移实施成本

传统数据库是功能的集大成者，分布式数据库因为发展时间较短以及分布式架构自身的复杂性，在功能上比传统数据库有所欠缺。若是缺乏的正是业务系统须要的功能，每每就要经过修改业务系统来解决。除了系统改形成本，还有运维成本，人员知识结构更新带来的成本，等等。

第三大挑战：新产品的质量和服务

最后一点是新产品的质量和服务可否知足金融业务的要求。数据库产品和其余产品的重要差别在于它关乎企业的核心数据资产。数据库新产品的质量不能仅仅依靠测试报告来保证，而是要看有没有通过实际业务的长期锻炼。对于应用过程当中出现的任何问题，技术研发和服务团队有没有能力限期解决。

上述的三个问题，是技术决策者须要思考和解决的。

OceanBase 2.0的发布，在必定程度上就是为了解决上面的三个问题，减轻技术决策者的决策风险。今天的报告分红以下六个部分，分别介绍OceanBase2.0在减小分布式架构对业务的影响、提升数据可用性、加强运维能力、提高性价比和产品兼容性方面的进展，最后还会谈一谈2.0版本在今年“双十一”大促中将要承担的任务。

业务透明的分布式系统

对分布式数据库而言，若是对业务能表现成一个具有动态伸缩能力、功能完备的高可用单机数据库，那基本上就达到了向业务屏蔽分布式架构复杂性的目标。把分布式架构实现的复杂性留给了本身，把便利性提供给了业务。为了这个目标，OceanBase 2.0版本实现了全局一致性快照，支持了全局索引，丰富了负载均衡策略。

1. OceanBase的总体架构

先来看一下OceanBase的架构，从1.0版本就确立下来的对等节点无共享存储分布式架构。集群中的每个节点都是对等的，包含完备的SQL、事务、存储引擎，负责管理一部分分区，并响应客户端的请求。

在全部的节点中，有部分节点承担了集群全局性的管理功能，图例中的Root Service节点，略微有点特殊，可是这个管理能力是其余节点都具有的，在必要的时候能够随时接管。

为了高可用，数据一般有多个副本，分布在不一样的可用区，图例中部署有三个可用区，单节点故障、单可用区故障都不会影响系统和数据的可用性。在9月20日ATEC主论坛中演示的“三地五中心”高可用架构，在发生城市级故障的时候数据不丢失，26秒恢复业务，用的数据库就是OceanBase。OceanBase也是云数据库，单个集群服务多个租户，租户之间数据和资源隔离。

2. 全局一致性快照

在没有实现全局一致性快照以前，分布式数据库在功能上是有比较大的欠缺的。有两个典型问题：一个是没法实现跨节点的一致性读，另外一个是没法保证因果序。

没法实现跨节点的一致性读，对于应用系统设计和开发人员是颇有挑战的，他们得保证在一条SQL语句中访问的多个表、多个分区都在同一个节点上，不然这个查询就会出错。

没法保证因果序的一个表现是：用户在两个事务中分别修改了位于两个节点上的两张表，先修改了源表，再改了目的表。但在另外的一个观察者看来：后修改的表已经在查询中反映出来了，但源表尚未变。这对于依赖操做顺序的业务系统，简直是个灾难。

OceanBase 2.0版本实现的全局一致性快照，从根本上解决了这些问题。相对于Google Truetime基于原子钟的硬件实现，OceanBase的全局时间戳（GTS）服务是纯软件实现的。不依赖特定的硬件设备，也不对客户方的部署环境提额外的要求，使得OceanBase可以服务更普遍的专有云客户。

全局时间戳（GTS）服务是系统的基础服务，该服务的性能和可用性对系统有很大的影响。OceanBase 2.0的单个全局时间戳服务1秒钟内可以响应2百万次以上的时间戳获取请求，知足单租户百万级TPS的要求。在系统满负荷运行的状况下，对性能的影响不超过5%。时间戳服务的高可用机制和数据分区高可用机制相同，后者在过去几年中经历了支付宝生产系统严苛的检验，很是稳定。

2.0版本的全局时间戳服务缺省打开，跨节点读写、因果序的行为和单机数据库彻底一致。对于数据都集中在一台机器上的小租户，或者对性能有极致要求的租户，能够选择关闭本身的全局时间戳服务。

3. 全局索引

全局索引是单机数据库的经常使用功能，在分布式数据库中比较难实现。对于分区表来讲，全局索引的价值在于为不带分区键条件的查询提供一种性能提高手段。在没有全局索引的时候，不带分区键条件的查询性能是比较差的，要在每个分区上作一遍这个查询，而大部分分区上根本没有知足条件的记录。

咱们看到，有些业务不能接受这么长的查询响应时间，就会建立另一张表来模拟全局索引的功能，这个额外建立的表的维护就会带来不少问题，数据一致性、以及在何种状况下使用这个表都须要应用系统去管理。

全局索引功能将业务从这些问题中解脱出来。在全局索引的建立和使用上，OceanBase都基于代价作选择，在建立的时候，能够基于基本表，也能够基于另一个索引。大表的索引建立一般耗时较长，对于大规模的分布式系统，设备故障也并很多见，为了提升建立索引成功率，在发生错误的时候采用子任务级别的重试。

对于查询优化器来讲，什么时候采用哪个全局索引也是基于代价计算的，目前索引回表查询是经过在计划上生成基础表和全局索引表的链接操做来实现的，代价模型也和通常查询相同。对有全局索引表的DML和查询操做很容易产生分布式查询和分布式事务，为了提高性能，在实现上作了不少细节优化，好比对于分布式查询，将任务的粒度从以前的分区级提高到节点级，以便减小RPC的次数。

4. 负载均衡

在负载均衡方面，2.0版本丰富了均衡策略。租户内的负载均衡让该租户上的工做负载能比较平均地分配在租户的多个节点上，对于数据装载和分析型的查询，能够有效地减小响应时间。此外，还能够设置租户间的亲和关系，实现将负载高峰出现时段相同的租户分布在不一样节点上，峰值时段不一样的租户分布在同一个节点上，充分地利用系统资源。除了提供给用户可配置的手段，负载均衡还结合CPU、Mem、存储等资源的使用状况，在负载差别超过阈值的时候，自动平衡节点间的负载，简化运维操做。

数据持续可用

在9月20日下午蚂蚁金服副CTO胡喜的主题演讲中，演示了OceanBase三地五中心城市级故障无损容灾方案，树立了金融核心业务高可用新标杆。

这一场三地五中心方案的现场演示是咱们1.4版本支持的特性。在提高数据可用性方面，2.0版本也有了显著改进，索引实时生效、闪回查询、在线分区分裂，这三个新特性，每个都解决了业务使用中的痛点。

1. 索引实时生效

了解OceanBase以前版本的同窗都知道，索引生效和每日合并是强绑定的，普通索引的生效要通过一次每日合并，惟一索引要通过两次。有的时候，索引建立失败了，业务还不知道，形成了很大的困扰。

在2.0版本中，索引建立和每日合并解耦，索引基于数据的一个全局快照建立，再合并后续的变动，建立成功便可使用。若是出现错误，也能及时给用户反馈，提高了用户体验。经过先在一个数据副本上建立索引，成功之后再经过复制的方式生成其余的副本，避免同时在多个副本上建立索引形成的系统资源浪费。支持建立全局惟一索引，进行全局惟一性检查；在数据一致性校验方面，和以前的版本同样，会检查索引和表中的相同列的一致性。

2. 闪回查询

闪回查询功能，能够指定查询某个历史时间点的数据，对减小用户误操做形成的影响颇有帮助。假如用户不当心删除了一些有价值的数据，能够经过指定删除以前的时间点来查询以前的数据。

在OceanBase的实现中，内存中的修改记录本来就是多版本的。为了支持闪回查询，要求转储到外存中的数据也要保留多个版本。至于保留多长时间范围内的版本，用户能够根据本身的须要进行配置，每个表均可以按需单独配置。为了减小多版本转储对存储的压力，存储层也将数据编码和通用压缩应用在转储上，有效地减小存储消耗。同时，在执行查询语句时，若是指定了快照版本号，查询也能够在从副本执行，分担主副本节点的压力。

3. 在线分区分裂

另一个提升数据可用性的功能是在线分区分裂，该功能对系统扩容颇有帮助。在业务早期设计表的时候，对将来的增量颇有可能预估不足，因此业务发展起来之后，就须要把单个分区再拆分，分红多个分区，再用多台服务器来服务这些分裂出来的分区，达到系统扩容的目的。

若是须要拆表的业务不能停服务，拆分操做就须要在线完成。在2.0版本中，分区分裂分红两个步骤，逻辑拆分和物理拆分，逻辑拆分是在表模式上把单个分区变成多个分区，完成表的元信息更新。物理拆分是把原先单个分区中的数据移动到新生成的分区中去。逻辑拆分在用户的DDL语句返回的时候就完成了，物理拆分是后台运行的。在物理拆分没有最终完成前，仍然会用到以前分区的数据。

在分区分裂的过程当中，也控制了存储空间的使用，旧分区某一个宏块的数据所有被转移到新分区了，该宏块空间就被回收了。

在分布式系统中，分区大小对负载均衡、副本迁移、复制都有影响，把分区控制在较小的规格是有价值的。在线下OceanBase 2.0测试集群中，单个节点可以服务百万个分区；线上生产系统单节点服务十万个分区。知足分区拆分以及云环境下对单节点分区服务能力的要求。

可运维性加强

分布式数据库相对于单机数据库，不管是部署仍是运维都要复杂一些，因此提升系统的可运维性也是2.0版本的一个重要目标。今天主要讲三个方面：DB Replay功能、在线升级以及新运维管控平台OCP2.0。

1. DB Replay

DB Replay是一个颇有用的功能，一方面能够下降系统升级的风险，另外一方面也能够用来作压测，保障大促。DB Replay主要分红三个部分：线上流量抓取，要求不能影响线上系统的服务能力；第二部分是流量分析，由于真实系统的流量很是大，抓取的数据量也很大，对分析的性能要求高，同时为了更接近抓取时的Session并发状况，在并发语句相关性分析上，粒度是行级而不是同类产品一般采用的表级；第三个部分是流量回放，保持和线上系统一样的会话之间的关系，而且能够经过调整语句之间的时间间隔来放大或者缩小对系统的压力，达到压测的目的。

2. 在线升级

做为长期支持核心业务的数据库系统，对升级的要求就是平滑、可灰度、可回滚。版本之间的数据格式是兼容的，新版本的程序能理解老版本的数据。同时经过可用区轮转升级，能够作到在线升级；在升级的过程当中能够灰度切流验证，在出现异常的状况下能够回滚，不会对系统形成严重影响。

3. 新版云管控平台

数据库运维管理一直就不是一件容易的事情，对于分布式数据库更是如此。“工欲善其事、必先利其器”。OCP（Open Cloud Platform）2.0就是一款专门用来管理OceanBase数据库集群的管控平台，经过OCP平台，能够一键安装、部署、升级OceanBase集群，监控集群的运行状态，建立和维护运维任务。

相对于1.0版本，2.0版本进行了架构上的改造，提高了服务的可用性，去除了对HBase、JStorm等外部组件的依赖，减小了最小化部署对服务器资源的消耗，从原先的3台物理服务器到2个Docker，很是适合对成本敏感的专有云客户。同时提供SDK供第三方定制管控平台。在服务能力方面，OCP集群可以动态扩展，每秒可以响应百万次的http请求，充分知足运维须要。

性价比提高

针对性能，咱们主要作了两方面的工做：提交协议的优化和工程实现层面的优化。提交协议优化指的是对分布式事务二阶段提交协议的优化，在这一方面，目前在申请相关的专利，这里暂时不展开。在工程实现优化方面，咱们作了大量细致的工做，包括内存分配、临界区、数据类型转换等。在下降存储成本方面，经过对静态数据进行编码，有效地减小了存储使用。经过这一系列的改进，在OLTP场景的实际应用中，2.0版本相对于1.4版本，性能提高了50%以上，存储降低30%。

兼容性提高

最后说说2.0版本的兼容性，咱们花很大的力气作兼容性，就是要减小数据库迁移形成的业务系统改造，下降迁移成本，同时使得业务数据库设计人员、开发人员、数据库管理员原先积累的知识和经验可以在新系统中复用。

1. 两种兼容模式

在1.x版本中，咱们主要作的是MySQL兼容。2.0版本支持两种兼容模式：MySQL和Oracle，目前Oracle兼容还比较有限，不久以后会有一个显著的提高。同一个集群中的多个租户，能够采用不一样的兼容模式，在租户建立的时候指定，后续不能更改。对兼容性的要求，不只仅是语法层面的兼容，还有语义方面、异常状况下的行为、并发行为、甚至于性能，均可以看做兼容性表现的一部分。

试想一下，一样的语句，新系统的响应时间是原系统的10倍，哪怕是语法兼容作得再好，也根本没法知足业务要求，又有什么用呢？

2. 存储过程功能

在功能方面，2.0版本实现了一个标志性新特性—存储过程。咱们实现存储过程，有两个方面的目的：一个是兼容性，咱们了解到，在传统行业中仍是有很多系统是基于存储过程实现的。经过支持存储过程能够显著下降这部分系统的迁移成本。另一个是高可用，经过使用存储过程，能够显著减小业务系统和数据库服务器之间的交互，若是业务流程的几十条、几百条SQL语句经过一个存储过程来实现，即使出现跨城的业务对数据库的调用，也不会对用户体验有明显的影响，系统的容灾将会更容易实现，稳定性也会更高。在为数很少的原生分布式数据库产品中，OceanBase是第一款支持存储过程功能的。

存储过程也支持MySQL、Oracle两种模式。若是业务不想让数据库来管理代码，也能够采用匿名块的使用方式，既有开发灵活性，又能得到存储过程带来的好处。存储过程采用LLVM编译执行，效率比解释执行高；支持基本调试功能，方便对大规模存储过程的开发和调试。

OceanBase 2.0的第一个“双十一”

做为阿里系的产品，不通过“双十一”的考验是不完整的。今年是天猫的第十个“双十一”，也是OceanBase 2.0经历的第一个“双十一”。

虽然刚刚出道，也要堪当大任。2.0版本将要承担一大部分支付宝的核心业务，同时，借助于2.0的在线分区分裂技术和全局索引功能，业务核心表要实现拆分，从非分区表拆成若干个分区表。

今年大促的峰值流量预计会大幅增长，但数据库服务器的成本不能增长，要靠提高数据库性能来帮助实现“零新增成本大促”这个目标。

听到这里，你们应该明白了，2.0版本所作的技术创新和产品改进，都来自于业务的真实需求，也会很快接受业务的检验。这是推进OceanBase数据库不断向前发展的原动力，也是OceanBase区别与市场同类产品的最大不一样。咱们输出到外部市场的产品都是通过内部业务严格检验过的，每一年的“双十一”大促都是对OceanBase数据库独一无二的压力测试。

最后，以OceanBase 2.0相关的几个数字来做为结尾：

“1”

第一个支持存储过程的原生分布式数据库系统

“30｜50”

存储减小30%，性能提高50%

“100万”

单台服务器的分区服务能力达到100万个

“200万”

单个租户GTS服务能力达到每秒200万次

OceanBase 2.0技术交流群

想了解更多 OceanBase 2.0 特性？

想与蚂蚁金服OceanBase的一线技术专家深刻交流？

扫描下方二维码联系蚂蚁金服加群小助手，快速加入OceanBase技术交流群！