OceanBase：为金融提供技术创新与金融服务

OceanBase：新一代面向金融的分布式关系数据库

2017-03-23 原创/冯轲 蚂蚁程序猿

首先回答OceanBase是什么？我记得在一两年以前，在很多的技术社区里，经常会碰到这样的问题，有同学问OceanBase到底是不是一个数据库，是不是一个Key-Value数据库？甚至有同学问阿里的数据库是怎么研制出来的，是不是从一个开源的数据库改造而来的？最近一段时间这样的问题已经非常少了，但是我还是想简单说一下。OceanBase它是由阿里巴巴、蚂蚁金服集团自研的数据库，我们拥有对OceanBase所有源代码的完整的知识产权。

如果在三年前让我说OceanBase是什么？我可能会说OceanBase是一个分布式的存储系统，但是发展到今天，再让我来说，我可以非常自信的告诉大家，OceanBase它已经是一款通用的全功能的关系型数据库产品。



作为一款基于分布式架构的这样一个数据库，OceanBase有非常多的技术优势，但这里面最为核心的我觉得是OceanBase它能够完全的基于普通的PC服务器，来构建一个能够满足金融级的可靠性和数据一致性要求的数据库集群。

前面提到OceanBase是一款自研的数据库，其实像数据库这样的我们把它叫做基础软件类的产品，国内目前在自研基础软件类产品的团队其实还有很多。那对于所有的这样的团队来说，其实在他们的发展过程当中都会面临一个非常关键，同时也是事关生死的问题，就是你如何让你的客户相信你的产品是稳定可靠的，你的产品是可用的？那要证明这一点，很多时候是需要这个产品在典型的应用中长时间的稳定运行，所以很多时候就会形成一种死结。

OceanBase是诞生并成长于阿里巴巴、蚂蚁金服集团这样的快速增长的互联网企业中，这样一个快速增长的互联网企业它本身就是一个巨大的数据库的应用市场。所以OceanBase这几年的发展实际上就是在这个市场中不断去证明自己的过程，通过在这个市场中的持续的应用来帮助OceanBase加快产品成熟，来帮助OceanBase去度过了对于一个自研的基础软件产品来说最为艰难的应用关。

而蚂蚁金服也通过OceanBase的应用，真正实现了所有核心业务100%的去O。到了今天，OceanBase已经在数十个关键业务上上线运行，这里面包括了支付、交易、账务，也包括了网商银行等等系统。这里面很多的核心系统实际上已经稳定运行了多年，期间也经历了多次的双十一大促这样的实战的考验。



在去年我们正式发布了OceanBase的最新产品OceanBase1.0。OceanBase1.0在整个系统架构和产品的性能和兼容性方面都取得了长足的进步，最重要的是OceanBase1.0它是整个OceanBase产品发展史上第一款真正具备大规模应用和推广能力的产品。



接下来会从几个方面向各位介绍OceanBase的一些重要的特性：



我们知道商业数据库扩展模型本质上就是一种单机扩展，通过在系统中引入处理能力更强，可靠性更高，但是价格也更昂贵的软硬件设备解决系统的可靠性和扩展性问题，这样一种扩展模型我们也叫做垂直扩展。垂直扩展有它非常重要的优点，它的优点是整个系统的整体交付度非常好，所以垂直扩展对业务是非常友好的。

但是垂直扩展有两个缺点：第一成本非常高，第二扩展性比较差。在以互联网行业为代表的企业，它在面对自身的业务的快速增长和现有的IT系统在扩展性、成本方面的矛盾的时候，它选择了在数据库以外来解决系统的可靠性和扩展性的问题。简单的说就是在业务层面，在业务的数据层面进行拆分，把原来有一个数据库集群完成的功能划分成了多个独立的单机数据库。把原来许多由数据库应该完成的功能去交给一个统一的中间层来管理，这就是我们经常说的分库分表模型。

这种分库分表模型有它非常重要的优点，有两点：

第一点就是整个数据的划分是在应用的设计初期就已经决定的，所以这种模型通常它有比较好的水平的扩展能力。

第二点就是这种以中间层为核心的扩展大大降低了对于硬件，包括对于数据库自身的依赖，所以使得整个系统的成本能够显著的降低。

但是这种中间成本模型有一个非常重要的缺点，就是它对业务的侵入是非常重的，采用这样的模型通常需要业务本身进行比较大的改造。对一个企业的整体的IT建设能力，包括它的运维能力都提出了一个很高的要求。所以目前我们看的这样的一种模型如果要复制到互联网以外的行业其实是存在非常大的挑战的。

OceanBase希望在这方面能够做得更多，希望通过我们产品本身的能力，能够把系统的可靠性和扩展性问题重新纳回到数据库的范围中来。基于一个统一部署的分布式的数据库集群，用户使用OceanBase不需要了解数据怎么分布，不需要去感知负载怎么均衡，甚至不需要关心系统怎么容灾，从而能够在继续保持一个低成本、线性扩展的基础之上尽可能的降低对现有业务的改造，简化业务架构的设计。所以这就是OceanBase一个非常重要的客户价值：对业务透明。

我前面说OceanBase是一个扩展性很好的分布式集群，但是其实了解OceanBase的同学可能知道，在早期的OceanBase场景里面，系统实际上是存在单点的。具体说就是集群当中每一个节点都可以提供读服务，但只有一个节点可以提供写服务，有点像传统的读写分离的设计。这是早期性的选择，这个架构的问题是，系统的可靠性和扩展性是单点的，业务写入能力的提升依靠垂直扩展，所以在OceanBase的1.0当中我们首先就解决了这个问题，真正实现了全对等的集群。在目前集群当中，所有的节点都可以提供读写服务，这就使整个系统的扩展性和可靠性有了质的飞跃。这种架构的推出也使得OceanBase的整体架构趋于稳定了，这一点非常重要，这就使得OceanBase在接下来的产品和技术这边能够加快发展奠定了很重要的基础。



在OceanBase1.0当中，我们也正式引入了数据分区的概念。数据分区是目前的OceanBase实现扩展性和高可用的基本单位。数据分区和我们说的分库分表中的分表在功能上非常类似，都可以支持扩展，但是唯一的差别是数据分区是通过数据库内核自身实现的。用户通过定义数据分区，系统可以帮助业务自动完成多机的扩展以及系统自动的容灾，整个过程是对业务透明的。我们希望未来有更多的业务能够使用分区，替代掉已有的分表，帮助他们简化在中间层的设计。



OceanBase的可用性

传统的关系数据库的主备架构，不管一主一备还是一主带多备，不管主备之间基于强同步的最大保护模式，还是基于弱同步的最大性能模式，主备之间任何一个节点发生故障的时候，系统要么选择停服务，要么选择忍受主备之间的数据可能不一致。对于关键业务来说停服务不可以接受的，意味着这种架构下面，当我们主备切换的时候，系统通常要丢数据的。OceanBase很好的解决了这一个问题。

OceanBase的核心它是Paxos分布式选举协议的工业实现，Paxos协议本身是多数派的协议，在Paxos协议下面，对于数据库的任何的变更都需要多数成员同意之后才可以进行。这句话可以反过来理解，对于数据库的任何的变更也只需要多数成员同意之后就可以进行。所以在Paxos协议下，任何少数成员的故障不会影响系统的可用性和数据一致性。

下图是一个简单的三个节点的OceanBase的集群，一主两备，在Paxos协议下，三个节点之间任何一个节点故障，系统既不停服务也不丢数据。同时如果主节点发生故障，另外两个备节点可以在很短的时间内自动的重新选举出一个主节点出来恢复服务，目前故障恢复时间在OceanBase层面是20秒，加上业务的层面是数十秒，不超过一分钟，这不是实验环境的数据，这是很多真实故障下面的实际的表现。

(www.chuimin.cn)

基于OceanBase的这种高可用的架构，我们可以根据业务的不同的容灾能力的需求，以及机房条件可以进行数据库集群的跨机房的部署。

简单介绍一下三种比较常见的部署模式：

第一、本地部署

这个模式比较简单。业务流量只能够被部署在本地，我们知道Paxos协议要求多数派，三个成员以上才能够形成多数派，所以我们要求至少三个机房，数据也是三个副本。这个部署模式具备机房级容灾能力，当发生城市级故障的时候系统是不可以服务的。



第二、本地部署+异地灾备模式

同样的业务的流量只能够被部署在本地，三个机房当中两个在本地，一个在异地，这种模式同样具备了机房级容灾的能力，当发生城市故障的时候可以提供异地灾备的能力。很多场景下客户可能无法在当地找到第三个机房，所以采用这种模式也是不错的选择。



我们所需要付出的成本是在日常情况下面远程的灾备机房是不提供流量的。这里我们采用的是数据的5个副本，不是我们刚才看到的3个副本，为什么不是3个副本？因为采用3个副本，本地机房中的任何一台服务器发生单机故障的时候，这台服务器上的数据分区就只剩下两个副本，一个在本地的另外一个机房，另一个在灾备机房，这时候系统形成多数派就需要进行两个城市之间的强同步，这个在性能上是无法接受的。因为用于构建OceanBase的数据库集群都是普通的PC服务器，单机故障非常常见，这里引入了数据5副本，2+2+1部署，第一先确保每个机房中的副本数都不会形成多数派，第二如果本地机房中的某一个副本发生故障，本地的另外三个副本可以形成多数派，意味着单机的故障不会导致业务的RT，因为需要引入城市间的强同步而显著上升。

第三、多地部署的模式

这也是一种能够具备城市级容灾能力的部署模式，意味着可以把数据容灾交给底层的数据库实现，可以大大简化在容灾架构方面的设计。

要支持城市级容灾有两个点：首先业务流量本身能够多地部署，当发生城市级故障的时候，业务流量本身可以被切换到其它的城市。

第二点要支持城市容灾意味着我们在城市级别要形成多数派，这就意味着整个数据库集群需要至少跨三个城市部署。同样的数据也是五个副本，我们也避免单机故障导致业务流量进行跨城市的切换。要支持城市性容灾是有成本的，因为城市级容灾意味着对于数据库的任何的变更都需要在两个城市之间进行强同步，这就意味着任何更新事务的提交延迟会增加，这个延迟就是两个城市之间的网络同步延迟，这个同步延迟随着城市距离的不同，通常是在数个毫秒到数十个毫秒之间，所以要支持多地部署的模式，业务首先要评估，这样的一种延迟会不会对业务的性能容量造成一个显著的影响，如果有，需要进行优化，去减少同步链路上的更新事务的提交数量。



这里要说明的是不管采用哪一种部署模式，所有这些跨多个机房部署的节点，都是一个完整的数据库集群的一部分，OceanBase能够在这个数据库集群当中，自动实现流量的路由，故障的转移和负载的均衡。从业务的使用，或者是运维角度上看它是整体交付的，这就是前面说的最重要的客户价值，对于业务透明，这也是我认为OceanBase接下来最重要的工作方向。

这里给大家看一下我们目前的一个性能的水平，应该说OceanBase在架构稳定之后它在过去的一年里面整个性能水平已经有了非常大地提高。这个性能水平也是目前所有的三副本强同步的数据库产品当中所有有公开的性能测试结果当中最好的一个。



下面介绍OceanBase其它方面的特性。

第一个是Mysql全兼容。Mysql全兼容的工作量其实非常大，去年我们也投入了大量的人力进行相关产品的开发，到目前为止，OceanBase已经实现了从SQL语法、数据类型到系统函数等等全面的和Mysql兼容。作为这项工作的副产品，去年我们一共向Mysql开源社区提交了200多个有效的BUG。Mysql全兼容这件事情，大大地强化了OceanBase作为通用关系数据库的产品特征，并且真正的帮助业务不改一行代码迁移至OceanBase，降低了用户的迁移成本和学习成本，同时也使得OceanBase真正具备了大规模应用和部署的能力。



OceanBase1.0支持的另外一个重要特性是多租户。这个特性的推出，也正式宣告OceanBase成为一款云数据库产品，能够对外提供云服务，并支持业务上云。OceanBase对于多租户的支持是系统在内核层面的原生支持，我们叫做SaaS或者DBaaS架构。我们看到目前Oracle最新版本推出的多租户也是基于这个架构，而目前我们在市场上看到的大部分的云数据库产品，都是基于在不同数据库实例之间进行隔离的这样一种IaaS架构。OceanBase这种原生支持的架构与IaaS架构相比，它能够实现底层资源在不同租户间的共享，从而提高硬件的利用率，改善集群的部署的密度，同时多租户的资源隔离的特性也大大加强了产品在整个的资源的整合，包括系统化运维方面的能力。



这是OceanBase 1.0在其它方面的一些重要特性。



这里面有很多已经超出了Mysql的现有的支撑能力，在设计这方面的功能表现的时候，我们比较多地参考了商业数据库，比如OceanBase1.0引入了一套完整的诊断监控体系，这个监控体系很大程度上参考了Oracle，所以在ORACLE中很多基础的监控设施，比如Top SQL、Top Wait等等，实际上目前OceanBase都已经完整地支持。其它类似的特性，包括SQL Outline、Flashback、Materialzied Views等等，都是如此。这些特性使得基于ORACLE知识体系的客户，包括运维的同学，未来如果使用OceanBase，会发现在很多方面是很熟悉的。

刚才说的是OceanBase的一些内核的特性，作为一个完整的产品形态，OceanBase还包括一个功能非常强大的管理和运维平台OCP。



目前不管是内部客户、还是外部客户，不管是开发同学、还是运维同学，都基于这样同一个的平台来接入和使用OceanBase。通过OCP平台，我们能够为业务打造一个从业务接入、数据迁移、到上线部署、日常运维的一个完整的封闭的功能链条，从而帮助业务实现整体上云。

OceanBase经过几年的发展，已经在产品上积累了许多重要的技术优势，同时这几年在整个核心业务的稳定运行，蚂蚁金服已经向业界证明了OceanBase能够支撑金融级核心业务的能力。去年我们也通过阿里云平台，正式开启了OceanBase对外提供服务的进程，到目前为止，我们已经同部分的金融客户开展了实质性的项目合作，所以欢迎大家来更多的了解和使用OceanBase！