时至今日，“Big data”(大数据)时代的来临已经毋庸置疑，尤其是在电信、金融等行业，几乎已经到了“数据就是业务本身”的地步。这种趋势已经让很多相信数据之力量的企业做出改变。为了应对大数据的冲击，淘宝将以前的Oracle、小型机、高端存储模式转变到现今的MySQL、OceanBase、Hbase、MongoDB等数据库，并使用普通PC服务器。本篇文章来自蚂蚁金服高级研究员 阳振坤， 将会介绍OceanBase如何服务互联网金融业务，以及实现过程中的一些技术细节。
26页PPT解密支撑支付宝交易的分布式数据库系统——OceanBase
OceanBase进入金融级应用
4月2日，蚂蚁金服方面宣布，蚂蚁金服及阿里巴巴自主研发的通用关系数据库OceanBase已经开始支撑淘宝、天猫和聚划算的所有日常交易。 这个改变意味着OceanBase已经有能力满足互联网海量数据处理的需求，可以支撑复杂、高可靠的金融级业务。
随着互联网的发展，海量数据的处理越来越成为摆在大型互联网公司面前的问题。而传统的IT企业提供的服务，在系统可扩展性、性价比方面已经不再适用。
以数据库系统举例，一般来说，数据库系统的稳定可靠，取决于数据库软件、数据库服务器和数据库存储三方面。其中，数据库软件的维护升级总是让互联网企业比较头疼：数据库软件的维护升级有很大的风险，为了保障数据库系统的稳定可靠，企业需要匹配使用稳定性好的高端服务器和共享存储，但是这些设备不仅价格昂贵，性能和扩展能力也有限。
在这种情况下，2010年起，阿里巴巴、蚂蚁金服开始自主研发数据库系统OceanBase，这一系统从立项到开花结果经历了足足五年时间。
与传统数据库公司的产品相比，OceanBase的升级维护，不需要昂贵的共享存储、高可靠的服务器、数据库软件的许可费，可以将商业数据库成本降到一半以下。同时，分布式的系统，可以保证业务在服务器、存储、网络等出现异常情况的情况下不受影响。
实际上，OceanBase此前已经通过了“双十一”考验。数据显示，2014年双十一，支付宝支付峰值就达到了285万笔/分钟，是2013年双十一支付峰值的3倍。借助OceanBase全分布、全冗余、高弹性、低成本的海量交易与数据处理架构，支付宝顺利通过交易洪峰的考验。目前，OceanBase已经可以支撑淘宝、天猫、聚划算在支付宝的所有日常交易。
OceanBase服务互联网金融业务背后的技术
数据库系统不仅保存了现代企业的关键业务数据，而且对这些数据提供访问从而支撑着企业业务。因此，数据库系统的稳定可靠对现代企业至关重要。
数据库系统通常由数据库软件、运行数据库软件的数据库服务器硬件以及保存数据库数据的数据库存储硬件(即共享存储)组成，如下图所示：
数据库系统的稳定可靠，也取决于这三个部分。
首先是数据库软件 ，数据库软件厂商平均2~3年发布一个大版本，新版本发布前会进行反复测试。即使如此，数据库软件的维护升级依然有很大的风险，2013年6月中国工商银行系统不可用即是其数据库DB2的维护升级导致，2014年8月美国国务院签证数据库系统超过1周的不可用也是其数据库Oracle的维护升级导致。
其次是数据库服务器 。为了保障数据库系统的稳定可靠，传统数据库系统厂商推荐用户使用稳定性较高的高端服务器，这些服务器价格非常昂贵，难以扩展，并且扩展能力也十分有限。
第三是数据库存储(共享存储) 。数据库中的数据是企业最宝贵的财富，为了避免数据丢失，传统数据库厂商推荐用户使用稳定性较高的共享存储，同样地，这类存储设备价格非常昂贵，难以扩展，并且扩展能力也有限。
为了避免水灾、火灾或者其他自然灾害导致的数据库系统不可用甚至数据丢失，传统数据库系统通常还要搭建备库，出于安全考虑，主库与备库需要保持一定的距离，例如50km或以上，俗称主备镜像，如下图所示：
然而，尽管称为主备镜像，数据库的备库并不能保证与主库一致：假如强制要求两者一致，那么主库的每一笔事务都必须到达备库后才能提交和应答客户，这样一旦主库备库之间的网络异常或者备库异常，整个数据库系统将不可用，从而导致业务的中断，与主库备库部分数据不一致相比，业务的中断对于企业来讲更加不能接受，因而主库故障后业务切换到备库时，通常会有少量数据不一致。因此， 即使部署了主备镜像，传统数据库系统也不得不使用可靠性尽可能高的服务器和存储，以降低主库故障的几率，减少对业务的影响。 之所以要使用可靠的服务器和可靠的存储，本质上是因为传统数据库假设硬件(服务器、存储、网络等)是“可靠的”。
对于数据库，与传统企业相比，互联网企业大的不同之一是并发访问量非常大。传统商业企业、银行，用户需要通过收银台、银行终端、ATM柜员机、POS机等专用设备开展业务并访问数据库，几百和几千的数据库并发访问比较常见，几万以上的并发访问相当少见。在互联网上，每一个草根网民都可以发起购物交易并访问数据库，几十万的数据库并发访问时常可见，几百万甚至千万的并发访问都可以见到(例如双11下的淘宝、天猫和支付宝)。如此之大的并发访问下，商业数据库软件及其高可靠的数据库服务器和共享存储的成本成为了不可承担之重。
由于上述原因，OceanBase的一个基本假设就是硬件(服务器、存储、网络等)是不可靠的，另一个基本假设是单机(数据库服务器及共享存储)无法满足互联网业务的需求。因此，OceanBase必须是一个多机(分布式)系统，并且必须保证任何时刻出现的少量硬件(服务器、存储、网络等)异常不影响业务。
为此，OceanBase引入了Paxos协议，每一笔事务，主库执行完成后，要同步到半数以上库(包括主库自身)，例如3个库中的2个库，或者5个库中的3个库，事务才成功。这样，少数库(例如3个库中的1个库，或者5个库中的2个库)异常后业务并不受影响：
与传统数据库相比，OceanBase的另外一个关键特征是软件版本的灰度升级。主备方式的传统数据库是“单活”的，只有主库可执行写事务，尽管维护升级时可以先操作备库，操作完成后备库变成主库并且接受用户访问是一步到位的，如果新版本有问题，则业务受到影响：
传统数据库：升级前
传统数据库：升级中
传统数据库：升级后只能一次性地引入全部读写流量
OceanBase则是“多活”设计，即多个库(3个，5个等)每个都可以有部分读写流量，升级时先把要升级的库的读写流量切走，升级后先进行数据对比，正常后逐步引入读写流量(白名单，1%，5%，10%……)，一切正常并运行一段时间后再升级其他的库：
OceanBase之3机群(3库)部署：升级前
OceanBase之3机群(3库)部署：切走读写流量，准备升级
OceanBase之3机群(3库)部署：升级一个机群(库)
OceanBase之3机群(3库)部署：升级一个机群(库)后切回部分读写流量
OceanBase之3机群(3库)部署：升级一个机群(库)后切回全部读写流量
基于硬件不可靠的假设并且能够容忍少量服务器的故障，OceanBase使用了相对廉价的PC服务器代替高可靠服务器并且不再使用昂贵的共享存储，从而不仅提供了比使用高可靠服务器和共享存储低得多的成本，容忍少数服务器乃至少数机群故障意味着比传统数据库更高的可靠性。通过灰度升级，OceanBase避免了传统数据库的“一锤子买卖”的升级，极大地降低了数据库维护升级的风险。
