点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

2008 年，王坚从微软亚洲研究院常务副院长的位置上离职后，于当年 9 月加入了阿里巴巴集团担任首席架构师一职，负责集团技术架构以及基础技术平台建设。加入阿里没多久后，王坚就提出了“去 IOE”的想法，即摆脱过去 IT 系统中对 IBM 小型机、Oracle 数据库以及 EMC 存储的过度依赖。

2009 年开始，阿里举全公司之力投入到云计算的研发和使用中，这可视为取代 IOE 之举。2010 年，阳振坤加入了阿里，这位在 1999 年就成为北京大学首批长江学者、曾获得国家科技进步一等奖、先后担任北京大学计算机科学技术研究所副所长、联想研究院首席研究员、微软亚洲研究院主任研究员、百度高级科学家等职务的研究员，带领团队在阿里做出来了取代商业数据库的 OceanBase。

2013 年 5 月，阿里集团最后一台 IBM 小机在支付宝下线。2013 年 7 月，淘宝广告系统使用的 Oracle 数据库下线，也是整个淘宝最后一个 Oracle 数据库。2014 年，OceanBase 替换了支付宝交易系统中的 Oracle 数据库。2015 年，OceanBase 替换了支付宝支付系统中的 Oracle 数据库。2016 年，OceanBase 替换了支付宝最核心的账务系统中的 Oracle 数据库。2017 年，蚂蚁金服全面去 IOE。

从 2011 年开始参战双十一到 2016 年双十一支付宝支付峰值 12 万笔/秒的世界纪录，再到 2017 年双十一支付峰值达到 25.6 万笔/秒，再次刷新 2016 年创下的峰值纪录，这背后，是一个由 OceanBase 研发和运维组成的几十人的团队。2016 年的世界互联网大会，OceanBase 入选世界互联网领先科技成果，其它获奖公司还包括特斯拉、IBM、微软、卡巴斯基等。

在 6000 多名蚂蚁员工中，这几十个人辨识度很高，因为只有他们的工牌带是“土豪金”，而其他所有人的工牌带都是清一色蚂蚁蓝。“土豪金”工牌带是蚂蚁金服内部最高荣誉——CEO 大奖。2016 年 5 月，蚂蚁金服董事长彭蕾亲自为这几十位技术明星戴上了“土豪金” 工牌带，理由是这个小团队自主研发的 OceanBase 数据库，以远低于传统数据库的成本，更高的可用性，扛住了支付宝一次又一次自我刷新的支付峰值世界纪录，打破了 IT 核心技术长期被西方垄断的格局。

从 2017 年开始，OceanBase 跟随整个蚂蚁金服的金融科技开放，开始了向传统金融赋能的实践过程。2017 年年底，OceanBase 在南京银行正式上线，OceanBase 数据库为南京银行“鑫云+”互金开放平台提供金融级分布式关系数据库服务。OceanBase 还出口到了印度和美国等地，为当地的支付业务提供数据库服务。作为蚂蚁金服自研的分布式关系型数据库，OceanBase 从一开始的目标就是传统商业数据库的升级换代产品，并坚持走通用关系数据库产品之路。

经历了 7 年坎坷、成立的头三年一直被边缘化、多次面临解散的 OceanBase 团队，如今虽然集体戴上了“土豪金”，可是他们都知道 OceanBase 这样的中国技术奇迹，是阿里巴巴/蚂蚁金服举全集团之力所创造出来的成果，这个过程本身也堪称“奇迹”。2018 年 2 月初，OceanBase 团队的主干成员阳振坤、冯柯、陈萌萌、蒋志勇、杨传辉等与笔者展开了深入的交流，介绍了 OceanBase 的来龙去脉。

▌OceanBase：划时代的数据库

▲OceanBase 团队 SQL 开发方向负责人  陈萌萌

为什么 OceanBase 能够入选世界互联网领先科技成果，能够进入 IBM、微软等世界科技巨头行列？首先，简要回顾一下基础软件历史。自 1975 年微软公司创立、1977 年甲骨文公司创立后，逐渐出现了商用操作系统和商用关系型数据库产品。再加上 1995 年创立的 BEA 公司及其代表的商用中间件产品，传统基础软件的核心技术：操作系统、中间件和数据库，就此诞生。

除了 BEA 公司于 2008 年被甲骨文公司收购外，为什么后来全球再也没有企业能够超越微软和甲骨文公司的操作系统与数据库及中间件产品呢？这其中的原因很多，除了最早投入、培养了最多的相关技术研发人才和技术积累外，更重要的原因在于作为全球化的商用软件产品，无论是微软的操作系统还是甲骨文的数据库，都是伴随着全球用户集体使用、集体反馈、集体推动技术进步而打磨出来的。

实际上，无论是操作系统、数据库还是中间件，本质上都是软件和硬件集成在一起的优化技术，其目的就是通过软硬件集成调优来达到计算效率最大化、成本最优、用户体验最佳、兼容性最广、安全与稳定性最高等结果。以甲骨文公司的 Oracle 数据库为例，其广泛支持并行机、大型主机、小型计算机、工作站、个人电脑等多种计算设备，允许用户在不同计算设备上使用并迁移 Oracle 数据库，1994 年的时候 Oracle 关系型数据库支持超过 100 种硬件和操作系统环境，兼容多项国际及国家的数据库相关标准。

令 Oracle 数据库成名的，是 OLTP 联机交易处理也称为面向交易的处理过程，其基本特征是前台接收的用户数据，可以立即传送到计算中心进行处理并在很短的时间内给出处理结果，针对诸如银行、证券、民航订票系统等需要实时响应的关键性业务系统等。Oracle 数据库在全球的金融、电信、民航等各类系统和业务场景中得到了广泛的应用，在应用过程中不断改进技术，最终出现了一个“强者恒强”的结果。

正因为 Oracle 数据库在关键性的 OLTP 交易处理中占据了牢不可破的市场地位，这让后来的数据库厂商很难有机会再重复一遍 Oracle 数据库曾经走过的这样一个反复实践、反复打磨、反复修正的过程。原因很简单，不会有企业愿意把自己的核心业务拿出来，给新进技术厂商当实验田。所以在以 IOE 为代表的传统 IT 环境中，除了已经建立起市场地位的主流技术厂商外，其它的后起技术厂商包括开源技术开发商，只能在企业的边缘业务或当地政府扶持的业务场景下，才有少量的机会。

这种情况一直持续到近十年的云计算变革。云计算实际上是由大型互联网公司发起和主导的技术变革，在最近几年逐渐从互联网公司向传统企业蔓延。云计算的初衷是大型互联网公司为了降低自己的 IT 支出，而从 IOE 架构向基于廉价 PC 服务器为主的 IT 架构进行演变的过程。云计算最早起源于 2006 年亚马逊推出的 Amazon Web Service 网络服务，简称 AWS。而到了 2008 年王坚成为阿里的首席架构师，负责集团每年的 IT 规划与预算，这个时候王坚就意识到了 IOE 架构对于阿里长期运营成本的影响以及对未来业务发展的制约。

在 2008 年的时候，阿里的数据库就已经是全亚洲最大的数据库，也是 Oracle 最大的用户之一，那年阿里还没有启动双十一。从 2009 年开始的双十一，每年产生和处理的数据量都在爆发式增长，如果一直采用 Oracle 数据库的话，运营成本将是天价。而在另一方面，为传统 IT 环境而设计的 Oracle 数据库，并没有考虑到互联网的大规模、高并发、实时在线、大型网络优化等新兴需求。2008 年的时候，Oracle 数据库就已经难以处理阿里的大规模数据量了。

本质上理解，OceanBase 与 Oracle 数据库一样都是关系型数据库，但不同的是 OceanBase 是面向超大规模互联网公司的分布式计算环境而重新开发的关系型数据库，Oracle 数据库则相应可以理解为针对传统企业的计算环境而形成的“单机”数据库。

所谓“单机”数据库，首先指 Oracle 数据库所基于的硬件环境是 IBM 小型机和 EMC 企业级存储所构成的高度稳定共享存储环境，IBM 与 EMC 的企业级硬件本质上就提供了高度稳定的共享硬件环境。其次，Oracle 数据库以共享存储为理念，所有的数据库看到的是同一个数据磁盘、共享数据访问，因而可以确保所有的数据都可被访问到，而且底层硬件本身也稳定可靠，所以是“单机”视角。

陈萌萌目前在蚂蚁金服基础数据部（OceanBase 团队）负责 SQL 相关方向的开发工作。2006 年毕业于清华大学、2006 年到 2008 年在欧洲核子研究中心（CERN）负责网格计算调度器的开发工作、2009 年 5 月在美国威斯康辛大学麦迪逊分校获得计算机硕士学位，陈萌萌先后在 Oracle、华为美国研究所从事数据库的开发和研究，他于 2014 年 6 月加入 OceanBase 团队。

陈萌萌对于“单机”的视角有一个形象的比喻：就像今天使用 PC 服务器，要担心如果突然某台 PC 服务器挂掉了、甚至机房本身遭遇地震、火灾等极端情况，如何保障数据访问的稳定性。由于是完全基于 PC 服务器架构，OceanBase 在处理数据访问的时候，相当于把一台原来的小型机或存储设备从纵向“切片”成很多机器，再把数据分布到这些分散在不同的机器上，数据需要通过网络才能够被访问到。“以前是一个磁盘，现在看到的是几十个甚至几百个分布在不同地方的磁盘，怎么做查询优化？这个访问模式会非常不一样。”

过去的传统 IT 环境是集中在一个地点的高稳定、高可靠、高可用高端企业级设备，现在的云计算环境是分散在不同地点甚至跨国家区域地理位置的廉价 PC 服务器机群。OceanBase 与 Oracle 数据库是基于同样的数据库原理，但底层的基础计算环境发生了根本性的变化，这对于像亚马逊、阿里巴巴/蚂蚁金服和谷歌这样的互联网公司来说，有三条出路：一是与甲骨文公司合作，全面开放自己的业务和数据；二是采用 MySQL 等开源数据库技术进行改良；三是从头开始重新设计一个完全自主知识产权的数据库产品。显然，亚马逊、阿里巴巴/蚂蚁金服、谷歌都不约而同地走上了自研的道路。

这个原因其实很简单，如果与甲骨文公司合作，需要全面开放自己的业务和数据不说，更重要的是互联网公司的快节奏、快响应、快研发、与业务运维并肩开发等特点，已经超越了甲骨文公司等上一代 IT 公司的企业文化和公司机制。而对于开源技术来说，不同的开源数据库只适用于特定的业务场景，由不同的开源社区“各自为战”式主导各自的技术方向，互联网公司需要针对不同的业务场景拼接不同的开源数据库到一个大系统中，这无疑也不利于长期发展。而走全面自研的方向，是一种最辛苦、看似最不可能却最具长期投资价值的选择。

马云曾经针对阿里自研云计算等新一代 IT 技术说：“网上很多人批评说我被王坚忽悠了，这个云计算要把 5000 台计算机合在一起，是根本不可能实现的……腾讯、百度没搞下去，重要的原因是他们的领导知道这个搞不下去。”相反，不懂技术的马云，却最坚定地支持自研云计算等新技术。“想也没想，从预算、人头、资金，我们一路投，最后我们走了出来。”

王坚从 2009 年开始在阿里搞云计算，阳振坤从 2010 年加入阿里后开始搞 OceanBase，两条线几乎是同时并进。阳振坤回忆，整个 OceanBase 其实并没有一个产品经理，根本的原因是 OceanBase 作为商用关系型数据库的升级换代产品，在 OceanBase 立项伊始就参照商用关系数据库列了一个长达千页的产品功能列表，随后的 OceanBase 开发过程就是根据这个列表，但却从分布式计算的角度重新实现每一个功能。“直到 2018 年初，OceanBase 还只是实现了这个列表中的部分核心功能，但足以支撑整个蚂蚁金服的业务”，阳振坤表示。从 2017 年开始，三年之内，OceanBase 要实现商用关系数据库的绝大部分功能。

能够与 OceanBase 类比、可以称为分布式数据库的产品，目前只有谷歌于 2017 年 2 月发布的 Spanner 数据库云服务。陈萌萌认为，Spanner 是谷歌从头开始全部自研的分布式数据库，也是针对谷歌的交易业务场景，但总体来说并没有阿里巴巴及蚂蚁金服的交易业务规模大，而 AWS 推出的 Aurora 数据库则更接近于 Oracle 数据库的共享磁盘设计。“真正用分布式架构解决像蚂蚁金服这么大规模事务性需求的分布式数据库，目前我们只看到 OceanBase 这一家”， 陈萌萌表示。

从第一行代码起步到今天的百万行代码级产品、支撑双十一的十万笔级每秒支付峰值以及蚂蚁金服的全面业务，OceanBase 可以说创造了一个划时代的数据库产品。OceanBase 是中国第一个具有自主知识产权的分布式关系数据库，也是全球首个应用在金融核心业务的分布式关系数据库。业内人士认为，OceanBase 的出现，在高端金融领域打破了传统商业数据库的垄断，为金融科技的国产化进程迈出了重要一步。

▌OceanBase：划时代的中国技术

▲OceanBase 团队架构师  冯柯

现任蚂蚁金服基础数据部（OceanBase 团队）架构师的冯柯，于 2014 年加入蚂蚁金服，目前的技术领域为分布式关系数据库、数据存储、性能诊断和优化。冯柯在入职蚂蚁金服前，曾在国内数据库厂商天津神舟通用数据技术有限公司（以下简称：神舟通用）任 CTO，是浙江大学计算机应用专业博士，具有 15 年的数据库研发和产业化经验。

作为国内最早一批从事国产数据库开发者之一，冯柯表示国内早期从事国产数据库开发的人们，基本都成为先驱了。以前做国产数据库，更多体现的是国家科研的意志，而不是企业的市场化行为。更为重要的是，自主研发数据库需要的是行业背景和企业实践。“数据库产品是用出来的，不只是被研制出来的。”冯柯强调。专注于国产数据库的国内的数据库专业公司，到后来往往发展的不好，就是因为没有行业属性、没有真正能够找到成熟应用的市场。

“我当时加入蚂蚁金服的时候，觉得蚂蚁金服自主研发 OceanBase 这件事其实很另类，觉得非常不可思议。而且阿里巴巴原来是开源文化，为什么会完全从头开始做一个数据库，这直到今天还是一个非常奇妙和神奇的事情。”冯柯回忆说，很多人都会问为什么不从 MySQL 开源数据库入手，“不管是自主研发，还是基于开源产品来做，从技术上面来看，没有绝对的对和错，很多时候是理想主义使然。”

正如马云所说，阿里巴巴/蚂蚁金服对于云计算和通用数据库等自研技术的投入，正是理想主义的结果。在 2017 年 9 月的阿里巴巴 18 周年年会上，马云说：“让阿里巴巴坚持 18 年的是因为我们有理想主义，坚持理想主义使阿里巴巴走到了今天。”“绝大部分人是因为看见而相信，很少部分人是因为相信而看见，”这是马云在阿里巴巴 18 周年年会上引用的话，“过去的 18 年，阿里是因为相信才有今天。”

蒋志勇现在是蚂蚁金服基础数据部（OceanBase 团队）SQL 组负责人，致力于高可用、高性能、高可扩展性并兼具成本优势的分布式关系数据库系统。蒋志勇于 2014 年加入蚂蚁金服，之前在神舟通用负责数据库开发长达十年之久。蒋志勇在浙江大学完成了计算机专业的本科和研究生学业后，即加入了中国航天科技集团下面的一家研究所，从事国产自研数据库开发，当时主要为了科研服务的数据库及存储系统。蒋志勇在研究生期间就已经参与到该科研项目中，后来就加入了航天科技集团组建的专注于国产数据库开发的神舟通用公司。

作为国内早期从事国产数据库开发工作的专业人员，蒋志勇认为蚂蚁金服开发自研数据库与其它专业数据库公司开发自研数据库的最大区别在于蚂蚁金服自有业务场景。“蚂蚁金服不是一家数据库公司，而是一家金融科技公司。OceanBase 在蚂蚁金服内部发展的一个基本前提，是能够为业务不断创造价值，这是跟传统数据库公司的最大差别。”

“之前的困境是开发了很多技术，但是很难找到一个真实的大规模场景去使用这些技术。但在蚂蚁金服这边就不一样，我们做的技术都是业务部门迫切需要的、确实能解决业务痛点问题的技术，加上蚂蚁金服的业务发展非常快，也逼着技术部门把产品做的更好，这是一个正向循环：不断促进技术开发，同时又能对开发成果提供真实业务场景下的及时反馈。” 蒋志勇介绍说。

作为整个 OceanBase 的始作俑者，阳振坤的感受最深。“做自研数据库，这真的是一把手工程，只有真的获得企业最高层的决策支持才能做成。对于业务部门来说，哪个数据库最稳定、最好用，就会选用哪个数据库，因为业务部门的首要目标是发展业务。”为了尝试自研数据库技术，蚂蚁金服的业务部门需要付出的代价是：修改业务系统，同时支持两种数据库，两边要能够随时切换，以便保证在自研数据库出问题的情况下，还能够切换回原有的 Oracle 数据库。“所以一开始业务团队在这件事情上其实并没有积极的理由。”

为什么说 OceanBase 是阿里巴巴/蚂蚁金服举全集团之力所创造的成果呢？阳振坤一直是从事分布式技术的专家，2006 年他从微软到百度，从事分布式系统研发。对于百度数以万亿计的网页来说，意味着与日俱增的天量数据，云计算系统有非常好的发展机会。阳振坤在百度做了两年多的自研分布式系统，但由于百度不愿意再投入更多资源而最终采用了一套现成的开源系统，阳振坤的团队也被解散了。

来到阿里之后，阳振坤与其它阿里技术人员一样，需要找到一个合适的业务场景，跟一个业务团队并负责技术，为自己的技术方向谋一条“生路”，同时随着业务的发展而壮大自己的技术。淘宝的技术“大牛”，大都是通过这条路径成长起来的。在加入淘宝之前，阳振坤其实并不懂数据库，他的本科与硕士都是数学专业，到了博士才转到了计算机专业，因此阳振坤的长项在于基础计算科学。

当阳振坤加入淘宝后，最开始选择自己技术方向的时候，恰好赶上了一个千载难逢的“天时”与“地利”。“天时”就是当时互联网对数据库的需求激增。以前金融企业等用的 Oracle 数据库，都是事先设计好业务场景，比如固定用于银行柜台和 ATM 机器、服务于固定的人群，数据库的并发量也很小，原来数据库有几十到几百个人、最多几千人的并发量就不得了，到了阿里巴巴双十一以及支付宝业务的时候，一下就激增到几十万、上百万人甚至是上千万人的并发访问，结果就是要原来的 IOE 投资要放大几百倍甚至几千倍，“谁都买不起了”。

而“地利”就是阿里巴巴/蚂蚁金服自有庞大的业务和数据库。“当时来阿里的时候，‘单机’在阿里系统内部就已经走到尽头了。IOE 等‘单机’的性能再好，也有个尽头；‘单机’的尽头，就是分布式系统的开始。” 阳振坤及其团队恰好是做分布式系统出身的，而阿里巴巴/蚂蚁金服内部有数以万计的数据库。虽然数据库作为 IT 系统的底层，一旦出现故障就会严重影响整个业务系统，特别是支付等关键业务系统。但阿里内部总有一些业务，因为数据量和自身业务需求等因素，可以先试用自研技术，从而打磨自研技术。

淘宝收藏夹就是这样一个业务，有大规模的数据量，其业务需求传统数据库又难以满足。2011 年的时候，淘宝用户已达数千万级，就算每人收藏十条即达几亿条的数量级。另外，淘宝收藏夹业务还有一个特点，就是数据库访问逻辑不太复杂，可以让 OceanBase 团队在短时间内开发出代码并投产使用。如果选择非常复杂业务作为目标，那么可能需要耗费技术团队几年的时间才能开发出一个可用的版本，而业务却不可能等这么长的时间。

这个项目取名 OceanBase，相对于 Database 而言，寓意要做一个海洋一样的海量数据库系统。完成了淘宝收藏夹的挑战后，很快就难以在淘宝内部找到类似的业务场景，可以让 OceanBase 技术团队继续生存下去。淘宝的核心业务已经应用了 MySQL 开源数据库并且比较稳定，MySQL 已经能满足淘宝的大部分业务需求。到了 2012 年的时候，OceanBase 团队面临要解散的危机。这个时候，王坚联系了当时的蚂蚁金服 CEO 彭蕾，把 OceanBase 团队推荐到了支付宝。而蚂蚁金服的 CTO 程立，又极大地支持了 OceanBase 的发展。2014 年双十一，程立出面，把交易流量的 1%切给 OceanBase，但实际的结果却是切了 10%，因为当时的 Oracle 数据库系统确实支撑不了汹涌而来的巨大流量。

后来的结果是 OceanBase 成功支撑了 2014 年双十一 10%的交易流量。但就在 2014 年 6 月份，当 OceanBase 已经从技术上准备好，需要切到交易业务时，因为业务系统改造的工作量大，导致 OceanBase 两个月都无法上线。“到了 8 月份，我急了，就给鲁肃（程立）和 Lucy（彭蕾）写邮件，这个事情后来就推动了。”

除了王坚、彭蕾、程立等阿里巴巴/蚂蚁金服等“一把手”对于 OceanBase 的大力支持外，当时负责阿里巴巴整个后台系统的刘振飞从第一天起就一直是 OceanBase 的坚定支持者。刘振飞于 2006 年加入阿里，曾任淘宝技术保障部总监，后来升至阿里巴巴副总裁负责技术保障部、是阿里巴巴合伙人之一，现任阿里集团首席风险官兼任高德总裁。正是刘振飞的支持，才让淘宝收藏夹用上了 OceanBase。“当时振飞负责整个阿里巴巴的后台系统，包括数据库，没有他的鼎力支持，OceanBase 无法在任何业务上线。”阳振坤回忆。

“甲骨文公司有十几万人，从事数据库核心研发的就有 2 千多人，而 OceanBase 一开始只有几个人，到后来也才 20 多个人，凭什么让别人相信我们能做出比 Oracle 数据库更好的技术与产品？这个确实听起来就不靠谱。”阳振坤说，这就是鸡生蛋、蛋生鸡的问题，好的产品必须要有好的口碑才会有人用，但好的口碑和好的产品却要在使用中才能打磨出来。数据库是做出来、更是用出来的，中国有那么多企业、高校和科研机构做数据库，真正能够在生产环境中大批量使用的少之又少。

今天回头来看，OceanBase 是阿里巴巴/蚂蚁金服举全集团之力而开发出来的自有知识产权数据库，如果没有阿里巴巴/蚂蚁金服内部众多“一把手”高管的鼎力支持，OceanBase 团队也许早就解散了。

▌技术成就：划时代的分布式数据库

▲OceanBase 团队复制数据库事务开发的研究员  杨传辉

通过核心业务的不断上线，蚂蚁金服帮助 OceanBase 渡过了自研基础软件产品最艰难的应用关。OceanBase 不只是被研发出来的，更是被用出来的，是在生产系统中被磨练出来的。蚂蚁金服作为互联网金融的标杆企业，也通过 OceanBase 的应用，于 2017 年真正实现了所有核心业务 100%去商业数据库，这对整个金融体系来说都是具有里程碑意义的事件。

今天的 OceanBase 已经支持了阿里巴巴/蚂蚁金服数百个关键业务的执行，其中有很多业务已经稳定的运行了多年。2017 年天猫双十一，支付宝创造了 25.6 万笔每秒支付峰值的业界新纪录，这对于数据库来说，意味着每秒需要同时运行 4200 万条 SQL。

市场对关系型数据库的性能和稳定性要求苛刻，真正的关系型数据库都是磨砺出来的——OceanBase 用了 7 年多的时间才取代 Oracle 成为了支付宝的账务等数据库。从 2010 年 5 月调研、6 月 25 日立项开始，OceanBase 的目标就是成为新一代的商用关系型数据库产品，差异化竞争点在于底层的分布式技术。全球三大数据库厂商已存在几十年，每家公司都拥有数以万计的员工，而 OceanBase 之外做分布式数据库的全球唯一一个成功案例是谷歌。

OceanBase 等后来者反映了以互联网为代表的新兴社会生产力对关系数据库的新需求：互联网访问的用户数量无法确定，可能在几天甚至几小时内增长数倍，传统数据库的垂直扩展方式根本无法应对。而全球前三大数据库甲骨文、IBM、微软都采用集中式系统的重要原因在于主机系统的稳定性，一台主机动辄数百万美元，存储空间不够就只能再买一台，而且新主机系统上线还要数天时间。

杨传辉现任蚂蚁金服基础数据部（OceanBase 团队）研究员，目前负责数据库事务开发工作，著有《大规模分布式存储系统：原理解析与架构实战》一书，他从武汉大学毕业后加入百度从事大规模分布式存储系统开发，后随着阳振坤转战阿里系从事 OceanBase 系统开发，是 OceanBase 0.5 和 1.0 版本的总体设计师。

杨传辉总结 OceanBase 的六大特点：第一高可用、第二强一致、第三易用性、第四高性能、第五可扩展、第六低成本。

OceanBase 作为分布式关系型数据库，最大的特色在于分布式架构，而分布式架构的一个基本特征是能够基于普通的 PC 服务器，构建一个满足金融级更高的可靠性以及数据一致性要求的业务核心。而 PC 服务器硬件的不可靠，可以通过架构设计和软件的可靠性来弥补，蚂蚁金服的多年实践已经非常清楚地向业界证明了这一点。

OceanBase 又被称为原生的分布式关系型数据库，即 OceanBase 是真正把所有与高可用及数据一致性相关的问题在数据库内核层面就解决掉了，这和现在很多互联网公司采用的中间层+单机数据库的分层设计方式有很大的差别。从技术复杂度上看，选择走原生分布式数据库这条路，无疑是非常艰难和痛苦的，这意味着在这样的一个复杂的分布式内核上，哪怕是实现一个简单的功能，也需要付出比单机数据库大得多的代价，但正是这样的选择，使得 OceanBase 真正具备了商业数据库最重要的特征：高度集成、整体交付，对业务无侵入；同时也真正解决了分层设计中无法同时实现的水平扩展及跨库查询等缺陷。

OceanBase 的一个基础设计思想是把每一份数据存放在三台不同的机器上，那么一台 PC 服务器出故障的概率为千分之一的话，两台同时坏的概率可能就是百万分之一，三台同时坏的概率则是十亿分之一。这样做的成本虽然下来了，但如何保证三台机器上数据的强一致性，这对于金融业务来说至关重要。

OceanBase 高可靠的核心是基于 PAXOS 协议。PAXOS 协议原来为分布式理论上的算法，OceanBase 在分布式数据库中实现了这一协议。PAXOS 协议本质是少数服从多数的协议，具体实现：在 n 个(n>=3)个数据库中，其中一个为主库，其余为备库，每一笔事务不是同步到所有备库，而是同步到超过半数的库（包括主库自身），比如 3 个库中的 2 个、5 个库中的 3 个等等。一旦主库故障，只要存活的库超过半数，就可以自动选举出新的主库，并且恢复所有已经提交的事务（超过半数库或者保证了每一笔提交的事务至少在一个库上存在），这样就允许少数的库故障而不丢失数据、不中断业务。基于 PAXOS 协议，OceanBase 能够实现单机/机房/城市级别，真正的无损容灾；在少数库故障的时候，RPO（恢复目标）为零，即没有数据因为故障而损坏或丢失；同时基于完全自动的主备切换，能把 RTO（恢复时间）缩短到 30 秒以内。

在强一致性方面，OceanBase 还做了大量优化工作。比如对于事务消息改造为异步消息机制：事务开始时把消息投入消息系统，当交易全部完成后才通知消息系统投递消息，而这个是一个非常关键性的改造，解决了高并发支撑同时的一致性问题。

所谓事务（transaction），这是面向 OLTP 交易型关系数据库的一个关键流程。对于交易来说，数据库的事务必须是“原子”的，典型的是银行转账：这边扣了 100 块钱，另一边就必须加上 100 块钱，而不能这边扣了那边却没有加上。

为了保证数据库的高可用，OceanBase 实现了三地五中心容灾架构在核心业务的落地，即使一个城市的所有数据中心都完全不可用，整个系统在数据层面仍然会做到不丢一行数据并继续提供服务。例如支付宝的会员 ID 采用了 OceanBase 的三地五中心部署方案，即使其中一个城市故障，剩下的两个城市至少还有 3 个活着的库，仍然能够自动选举出新的主库、立即恢复数据，并继续提供服务。

在易用性方面，OceanBase 作为后来者，必须要考虑到已有数据库用户的习惯，必须要兼容已经有的技术与产品，特别是在做数据库迁移的时候，最好是原有的软件代码不需要改动一行也能直接迁移到 OceanBase 上，这就是易用性。

在可扩展性方面，每一个城市里面的机房可以想象为一个可分片的大型数据库，可作为数据拆分的基础，例如把全中国的所有用户分成一百份，那么一份放在第一个机房，依此类推使得整体伸缩能力可达到机房级。理论上只要增加机房，就能无限增加伸缩能力。不论跨越多少个机房、多少个城市，所有参与部署的数据库服务器在逻辑上是一个 OceanBase 集群的一部分，这就是所谓“原生”的概念，无论从应用视角还是运维视角，都是整体交付。

通过原生的分布式数据库设计，OceanBase 实现了高可用、强一致、易用性、高性能和可扩展，这样带来的好处就是 OceanBase 性价比能做到传统数据库的 10 倍甚至更高，原先一台高端服务器动辄几十万、几百万，而 OceanBase 仅用几千元至多几万元的 PC 服务器即可，这从根本上来说就不是一个量级，诸如大型银行使用的大型机可能以几千万、几亿元来计算。阳振坤表示，OceanBase 的性价比已经达到了现有商业数据库的 5 倍~6 倍以上，未来还将达到更高。

OceanBase 的开发分为两条线：一条线是从 2010 年开始开发的 0.1、0.2、0.3、0.4、0.5 这一系列的版本，主要是早期为了服务当时已有的阿里系业务；另一条线是从 2012 年开始构想的、完全从云时代架构重新设计的分布式数据库 OceanBase 1.0 系列，2013 年开始整体设计、2014 年中旬抽出资源正式投入开发、2015 年底开发完成，后又经历了 1.0、1.1、1.2、1.3 到现在的 1.4 版本。

2016 年双十一的时候，有些支付宝业务还是基于 0.5 版本，有些业务已经升级到 1.1 版本，少量业务升级到 1.2 版本。而 2014 年双十一，10%的交易数据链搬到了 OceanBase 上；2015 年双十一，100%交易数据链和支付数据链都搬过来了；2016 年双十一，整个账务库都搬过来了，这一核心数据库被称为“金融系统数据库皇冠上的明珠”。

▌研发故事：软件、硬件、业务一体优化

▲OceanBase 团队 SQL 组负责人  蒋志勇

对于 OceanBase 这样一个划时代的分布式数据库，自然有写也写不完的研发故事，以下仅摘取几例以体现 OceanBase 的研发之难。

陈萌萌介绍说，以前数据库技术更多偏向软件层的，硬件层有专业人员、专业技术和专业的公司来解决硬件本身的稳定性或容灾等问题。但是在蚂蚁金服这边更多是软硬结合的方案，OceanBase 软件从设计之初就考虑了硬件层面不稳定、分布式系统的特征，从而去做以前数据库不会做的优化工作。以前的数据库优化根本不会考虑到底层的硬件损坏、机器宕掉、网络断网、天灾人祸不确定性问题，而今天 OceanBase 无时无刻不在考虑这些问题。“以前做软件开发，先假设底层的硬件没有问题，而只需要把上层软件逻辑做好就行了，现在我们是整体的软硬件考虑。”

以数据库的查询优化技术来讲，比如传统的银行柜台，通过人工窗口提供服务，用户的主要时间花在与人工窗口打交道等方面，对于数据库的快慢体会不那么敏感，但是蚂蚁金服是互联网应用，数据库随时的一个抖动或查询执行时间变慢了一点，用户马上就能直接感受到。这与传统应用场景差异很大，如果数据库的一个查询从一毫秒变到了五毫秒，传统数据库不会认为这是件大事，但是互联网应用下，多出来的四毫秒可能被放大成为几百毫秒甚至一两秒，一旦出现这样的时延，用户体验马上就变差了。“我们每天都在做特别精细的事情，生怕一毫秒变成五毫秒这种事情出现，因此做了很多精确防御。”

杨传辉进一步解释。数据库查询优化器本身是近似解，基本上不存在最优解，优化的目标就是逼近最理想的情况。在传统应用场景下可以允许优化结果差几个毫秒甚至更多，但是在互联网场景下就很难接受这么大的差异，所有的优化效果都要精确到几个毫秒以内。

比如每一次在支付宝付款，点击一下支付宝的付款按钮，背后的数据库可能要执行一两百次数据库的 SQL 查询，优化器要为每一个查询生成一个需要做的优化执行计划，如果优化器在某一个场景下犯了一个错误，每个查询多出了 5 毫秒，那么整个链路就会多 500 毫秒，用户在按下付款按钮的时候发现有可能变慢了。如果再加上可能不止做支付，比如买商品后下单再要支付，这几个链路加在一起就有可能慢几百毫秒甚至上到秒级，这对用户来说就已经不能接受了。

还有一个场景是地铁的刷脸或者刷支付宝进站，如果用户站在闸机前面半天刷不出来，那就不光是体验问题了，有可能会引来连锁麻烦，后面人也会被堵起长龙，这些现实的挑战都要求 OceanBase 反应精确、迅速。杨传辉介绍说，从关键业务系统的数据链路梳理上来看，一两百条 SQL 是最普通的一次交易了，如果涉及到支付渠道不一样，SQL 执行的次数就会更多。

因为蚂蚁金服本身是分布式的系统，分布式系统一个很大挑战是对底层的基础组件包括网络要求非常高。如果网络出现了问题，就会对整个服务产生影响。因此 OceanBase 不仅要对数据库层做优化，还对网络、磁盘、操作系统等软硬件层都要做很精确的优化。

那么 OceanBase 是怎么解决的呢？OceanBase 团队从业务的开始阶段就会介入到业务的设计当中，业务怎么用数据库、怎么用最合理等等，从一开始就会参与整体设计，与业务方和整个架构一起演进。

蒋志勇所从事的 SQL 引擎和优化器工作，为 OceanBase 从无到有的建立了自己的 SQL 引擎，特别是让原先的 MySQL 应用不改动任何代码就能迁移过来。在数据库的兼容性方面，OceanBase 做到了对 MySQL 的兼容，蚂蚁金服的内部业务从 MySQL 数据库迁到 OceanBase，不需要任何改动。

在优化器方面，涉及到的系统统计信息收集，是与蚂蚁金服的业务体系架构结合起来，设计了一个动静分离的架构：白天把统计信息都存储到内存中，每天到业务低谷的时候再从内存写到磁盘上。而不是像其他数据库那样直接写到磁盘上，导致收集系统统计信息慢且不全面；也不像内存数据库那样全采用高成本的内存来存储统计信息。OceanBase 的这种准内存数据库设计方式，既满足了 SQL 查询需要实时收集更全面系统统计信息的需求，也让整体的信息收集成本没有额外开销。

OceanBase 还在 SQL 语句搜索优化方面进行了精细化的调节。由于是完全自研的数据库，对于 Join 连接查询算法可以灵活适配多种算法，而在其他数据库中则由于已经限制可选范围而无法做到更精细的优化。“我们在搜索条件的改写上面做了巧妙的设计，结果就是有更广的可选择范围，而其他数据库则只能在一个很窄的范围内选择最优策略，因此 OceanBase 的搜索结果更优。”蒋志勇说。

因为要兼容 MySQL，OceanBase 团队也精研了 MySQL，对 MySQL 进行了大量调优工作。在这个过程中，OceanBase 团队发现了 MySQL 的几百个问题，向 MySQL 开源社区汇报后得到了确认。诸如 MySQL 对不同路径执行出来的结果都不一样、MySQL 的语义不是非常完整等等，都是 OceanBase 团队在使用 MySQL 中发现的问题。特别是由于阿里巴巴和蚂蚁金服的业务规模日益扩大，经常会踩到各种技术的极限门槛，OceanBase 团队就曾经在开发 MySQL 接口驱动程序的时候，通过业务排查发现某个事务已经回滚但数据还是被提交进入了数据库，导致会出现转账已经取消但钱还是被转走了的现象，团队排查了很久后终于发现是由于 MySQL 客户端的一个变量设置本身有问题，但这种问题只有在极限条件下才有可能出现，属于小概率事件。OceanBase 团队就是这样逐一排除小概率事件，最终走向了通用型产品的道路。

通用型产品与场景化产品最大的区别在于通用型产品能够适配绝大多数场景，而场景化产品则只能适配单一的场景。冯柯表示，这就是商业数据库最强的地方，因为能够匹配绝大多数的场景。也许商业数据库的技术不是最强的，但价格那么贵还有用户买，就说明商业数据库的总体拥有成本更低，一个产品就能适配大多数场景。而能够适配绝大多数场景，就说明把已经能踩的坑儿都全部踩过了，今天的 OceanBase 也在经历同样的过程。

OceanBase 踩过的另一个坑儿，也是在极限情况下才会出现的 Linux 系统 bug。OceanBase 本身是在 Linux 和 C 语言基础上开发的分布式数据库系统，2010 年到 2011 年 OceanBase 团队在支持淘宝收藏夹业务，2011 年双十一的时候遇到了稳定性的问题。当时的 Linux 有一个直接访问 IO 的特性，这个特性出现了 bug，而且是在极限条件下才会被触发的 bug。

杨传辉回忆当时距离 2014 年双十一还有不到一个月的时间，是一个周五出现的问题，导致淘宝收藏夹一天之内连续宕机三次、每次一个小时左右，每次宕机后恢复收藏夹的流量，一旦访问量超过一定量就又触发了 Linux 内核的 bug 导致再次宕机，直到周五晚上 8、9 点后淘宝访问用户变少后才恢复了运转。由于当时的开发团队主要集中在北京，因此第二天的周六早上所有团队成员搭第一班飞机从北京飞到杭州来解决问题。“当时的气氛很紧张，如果这个问题解决不了，OceanBase 团队当时就会解散。”杨传辉回忆当时的情况，而且在解决问题的时候，负责写代码的程序员的压力也很大，后面有两三个在盯着到底怎么写代码。“当时也并不确定这么做就一定能解决问题，只是觉得有 70%-80%的概率能解决问题，后来还真解决了这个问题。”

“阿里巴巴/蚂蚁金服的系统发展太快、一直在变，OceanBase 也一直在开发新功能，又要支持线上业务，而双十一的爆发可能会是平常流量的十倍，而像 Linux 内核 bug 这样的问题，如果只是平常流量的一两倍，是根本不会触发的，它只有在爆发十倍的时候才会出现。所以我们特别紧张，也没有时间让我们仔细去分析，慢吞吞地解决问题。当问题来的时候，所有人加班解决，就是这样。”杨传辉说。

冯柯回忆说，他加入 OceanBase 后的第一件事是做诊断监控，当时没有人愿意做这件事，因为最主要是要到系统中埋点，大家都认可这件事很重要，但是没有人愿意去做，因为它涉及到所有的模块，是一件非常吃力不讨好的事情。而自己当时选择做的原因，是因为这对业务来说非常重要，是必须要做的事情，当时也碰到了很多的挫折，出了很多问题。例如 OceanBase 诊断监控功能刚上线的时候，有 N 个人去看监控，会得出各种不同的结论来，“大家觉得这个功能完全不能用，觉得做得很烂，所以当时参加的同学很沮丧，觉得没有被承认”。冯柯当时鼓励团队，最困难的时候反而是团队进步最快的时候，“别人对你的批评最多的时候，其实是你进步最快的时候，你的产品能够获得更多资源，能够被更多的人认识到，这其实是非常好的，那个时候的触动确实很大。”

OceanBase 是一个一边在业务中“讨生活”，一边寻找机会发展壮大自己的过程。在“讨生活”的过程中，OceanBase 也会不得已做出妥协。杨传辉回忆 2010 年的 OceanBase 版本有一个比较大的缺陷，就是设计了单点写入。当时，把所有写入数据全放在一台机器上，这个版本可扩展能力比较差，本质上只能做垂直扩展而没有办法做水平扩展。另外，因为每个写入都要经过那个节点，最后整个性能也相对更差，数据库的功能也受限。这主要是 OceanBase 早期的版本，当时团队的数据库经验没有那么丰富，也没有时间做长期的开发，直到 2015 年重新设计开发的 1.0 版本才是真正面向云时代的分布式数据库。这个期间，OceanBase 团队也从各个渠道引进数据库人才，最终实现了数据库的重构。

OceanBase 经历的失败还有很多。杨传辉回忆，OceanBase 在 2012 年 11 月份转到蚂蚁金服到 2014 年实现了交易系统，这之间的 2013 年其实在从事淘宝的库存项目而不是交易系统。当时，OceanBase 团队看到库存的数据库问题也是一大挑战，这就像卖火车票系统的挑战本质上也是减库存问题——如果有两人同时并发减库存，就会乱掉。当时，淘宝的 MySQL 团队也在做这个事情，最终业务部门选择了 MySQL 的方案，就是因为业务团队当时觉得用 MySQL 更放心，“就这一个原因，也没有其他的点，最后没有选择 OceanBase，我们相当于那一年白干，整个团队白干。但因为这个铺垫，我们下一个交易系统真的做成了。”

▌OceanBase 的研发方法论

▲OceanBase 创始人  阳振坤

总结 OceanBase 的开发过程，总会试图寻找一些研发方法论，就像微软的软件开发“三驾马车”那样的方法论。但正如陈萌萌所总结的：“我们其实更多的时候是与运维、业务团队等一起在定义问题。我们会看到一些问题，找到真正要解决的问题是什么，然后帮助用户定义这个问题。在定义问题时，有时候我们会开一个会，分析某问题是由数据库团队解决、还是由业务团队解决，而在开会之前可能大家都不知道最后要达到什么样的效果。很多时候我们在做这些不确定的事情。”

OceanBase 本身是在做一个没有先例可参考的分布式数据库，纯粹做分布式系统，全世界谷歌做得最好。阳振坤在百度时所带领的分布式团队已经是国内当时最强的分布式技术团队，也从谷歌吸收了很多分布式技术的思想。但当后来试图把分布式架构与关系型数据库结合在一起的时候，就再也没有先人的经验，而只能靠团队自己琢磨。虽然 OceanBase 到目前为止还没有发表过论文、还是在做业务，但杨传辉回忆 OceanBase 中有很多是别人没有想过方法，可能要做一个新的方案要想好久，要思考半年到一年后面再决定去做。

在具体开发的执行过程中，测试是很重要的工作。分布式系统的异常处理很容易出错，平常机器不出故障，到上线业务突然出一个故障时，可能就是一个大故障，而这种异常处理的测试比较难。OceanBase 有容灾模拟框架，就是随时把一台机器杀死，而这样的容灾测试随时在运行。另外，对于并发处理的测试，即某个条件的达成可以突然触发两个线程的先后顺序或一个变量的访问顺序出错，OceanBase 也是随时在模拟这样的场景，让这样的小概率事件尽早出现。

在开发的过程上，OceanBase 通常是一个人写出来的代码，要另外一个人去读和审查，通过的代码才会提交。OceanBase 团队还写了很多自动测试用的框架，开发人员要自己做单元测试和一部分的功能测试，集成测试则由专门的人来完成，OceanBase 的测试人员很少只有几个人，大部分的测试都是靠自动化完成。

因为 OceanBase 是软件、硬件和业务集成在一起的整体优化，而当软件、硬件和业务碰到一起的时候，经常会出现各种碎片化的小场景问题，那么又是怎么解决的呢？陈萌萌介绍说，当遇到这样的场景时，就会提前把大家拉到一个钉钉群里，把需求丢到群中，技术团队根据需求提供反馈建议，业务团队也会反馈在试验中遇到的问题。这些碎片化的场景和问题，很难区分到是软件、硬件还是业务的问题，因此群里有运维、开发、业务甚至还有负责业务拓展的 BD 和负责产品的 PD，只要需要关注的人员都可以进到群里。陈萌萌透露他自己平常关注的活跃群就至少在 20 个以上，也就是至少一天发一条消息的群，他也在更多的可能十天半个月才发一条消息的技术讨论群中。

以前在甲骨文公司的时候，陈萌萌说大家更习惯用邮件的慢节奏沟通方式，到了阿里系就是碎片化的沟通。首先每个人有负责的业务或技术方向，空闲的时间就会把群里的来龙去脉都过一遍。有些群是按需找人，在群里被@了就肯定会关注这些消息，如果没有被@，就会找不是特别紧急时候再把群里的消息过一遍。虽然群很多，但是真正过群消息的时候，几分钟时间还是能够把过去几天的消息都过一遍。这样总是能区分哪些是需要第一时间响应的，哪些可以后续持续关注的。

一般 OceanBase 团队的工作时间是早 9 点到晚 9 点 12 个小时，但也有大促的“双十一”、“6.18”、春节红包压测等紧急情况。当然，随着 OceanBase 的发展，需要处理紧急事件的情况在减少。陈萌萌回忆，以前跟着业务团队压测到凌晨，甚至说半夜被揪起来的情况，会经常发生。

“我记得经历过很多故障都挺戏剧化的：因为一旦出现一些问题以后，各方面的人都会被半夜拉起来，大家临时被拉到一个群里面，谁也不知道当时发生了什么，但是每个人可能有一部分的信息，大家很快把各自的信息扔到群里面，这样就对出来到底发生了什么。每个人都有点胆战心惊，生怕自己做的那部分导致了什么问题。”陈萌萌回忆说。“我记得有一次故障，半夜 11 点说有一个问题需要大家上线去看，一帮人包括主管都上线看问题，一直到凌晨四五点。一开始大家都在，慢慢发现问题越来越聚焦，相关的人员就上来，一直到凌晨四五点才解决问题。中间大家在群里面各种排查信息分析，提出各种建议，虽然没有坐在一起，但就像关在一个屋子里面开了连夜的战斗会一样。”

陈萌萌总结了阿里这种独特的技术讨论群解决问题的过程：“这是一个不停过滤信息再分析的过程。如果一开始不掌握所有信息，谁也总结不了。对完信息后，有人发现说某个地方需要关注，别的人再把相关信息加过来，慢慢连成一个逻辑。当你回头再看群里消息的时候，这个现象特别明显。信息一开始是散的，然后慢慢才能达成一致，最后走下去。”

当然，群里也会有熟悉各种“疑难杂症”的“老中医”，一般是经验比较丰富的人员，见到的问题也比较多，所以别人可能还在猜测的时候，“老中医”就会给一个很靠谱的可能性，沿着这个可能性去看的话，发现确实可以通过这个角度去挖掘解决问题的方案。

然而，即使讨论出了可能的解决方案，“大家还是挺胆战心惊的，敲命令都是让专门负责运维的人员去敲，这个时候的关键在于手不抖、别敲错，因为万一敲错了那就是二次故障。所以我们都会找一个心理素质好的同事操作，大家谁也不要吱声，看着这个同事安静地把命令敲完。”因为不管通过群里的讨论，选择一条最保险最靠谱的操作方式，但在系统里面直接敲命令都有可能直接动数据，敲错一个键就有可能把所有数据都删了，这是没法挽回的，“所有人在操作的时候都不敢出气”。

当然，每次处理完故障后，也会复盘找到以后的解决方案，最后形成知识库也就是应急预案再固化到程序里，通过程序防止下一个错误。

前面提到整个 OceanBase 并没有一个统一的产品经理，因为 OceanBase 的功能列表是对标商业数据库。但还是会有产品开发的规划，通常以财年为单位、双十一为重要节点，比如某个版本必须要在下一个双十一之前做出来并且稳定运行，再通过双十一检验。“保持这样一个节奏”，蒋志勇补充。

▌成功之道：不断证明自己

“以前分布式系统谷歌里面是有的，但是数据库领域没有一个人用到生产系统里面。包括我们最初用 PAXOS 协议做数据库的时候，传统数据库从业人员带着原有思维看这件事，大家觉得不可思议。我们与蚂蚁金服的业务方交流，告诉业务方能同时做到一致性与可用性，不丢一条数据而且做到高可用，业务方觉得不可理解，因为业务方已经习惯了传统数据库的方式。”冯柯在回忆 OceanBase 早期的发展时，还是很兴奋当时打破了传统技术的思维。

改变一个人的思想是非常困难的事情。OceanBase 作为数据库领域的新进入者，优势在于把分布式系统和数据库结合起来。“其实 OceanBase 本身不是一个专业数据库团队，OceanBase 的创始人本身都不是学数据库的，而是最早从分布式存储开始做起，OceanBase 到很后面才真正有了 SQL 的功能。”作为传统数据库专家出身的冯柯说，OceanBase 最吸引他的地方在于有机会能接触到影响几亿人的业务。OceanBase 对于传统数据库也不是一味模仿，而是在分布式架构方面做差异化，“我们今天不是简单的功能模仿，每一个功能在 OceanBase 上，由于架构的不同，内涵其实是不一样的，挑战也不一样。其次，今天在 OceanBase 真正上线一个业务，马上就能服务到几亿人，这两点是非常吸引像我这样背景，包括从 Oracle 来的技术人员。因为 OceanBase 有非常好的应用场景。”

作为 OceanBase 的创始人，阳振坤经常强调数据库不是被研制出来的，而是被用出来的。今天 OceanBase 如果推翻重来，或许会有更好的方案，但在发展的初期很多时候要考虑团队的生存问题、满足业务和场景的需要，所以当时很多的选择是面向用户的选择，让更多的业务能够跑在 OceanBase 之上，通过这种方式来建立用户对 OceanBase 的信任。

“如果大家当时能看见原来七年后 OceanBase 能长成这样，我相信七年前的那个环境会好很多。但是这种如果是不存在的，很多时候你要先证明自己。”冯柯说。

杨传辉介绍说，OceanBase 从淘宝转到支付宝，很大程度上是因为 MySQL 可以满足淘宝的多数业务需求。淘宝属于电子商务类交易型业务，与支付宝的金融交易差别很大。当时淘宝电子商务交易是可以偶尔的丢失数据，采用了传统数据库的主备同步来实现高可用，但是主备之间是异步的，备机与主机的数据之间落后几毫秒都是有可能的，MySQL 主备同步模式已经能够满足淘宝电子商务交易。

从 2012 年底开始，OceanBase 开始慢慢支持支付宝的交易，支付宝交易属于金融系统，不允许有任何一条数据的丢失。淘宝如果数据丢失了一条，还有一个最后的手段，就是可以查支付宝。毕竟丢失数据的概率极低，只有在极端场景下才有可能丢失数据，而且还能向支付宝查询，支付宝就是最后的防线。2014 年，支付宝交易由 Oracle 切换成 OceanBase，实现了一条数据都不丢失，而且保证高可用、强一致。这在传统数据库都没有办法做到：既保证一条数据也不丢失，又保证数据的高可用。因为对于传统数据库来说，这两个要求是相互矛盾的事情。OceanBase 创新地采用了分布式系统里的 PAXOS 的协议，第一次把这个协议用于传统数据库和分布式系统两个领域的结合，并在 2014 年双十一中得到了检验，后面的发展就比较顺了。

蒋志勇回忆他刚来的时候，当时还是对于支付宝核心业务上 OceanBase 有很大的争议。“2014 年双十一的时候，争论很激烈，最后是 CTO 当时拍板要上 10%。当时在上 1%还是上 10%这方面大家很纠结，因为毕竟双十一 10%的流量几乎相当于平时的全量了。当时 CTO 拍板做 10%，并且后面还挺顺利。从那个时候开始，在核心业务上，大家就慢慢接受和认可 OceanBase 了。”

杨传辉回忆当时为了赶上 2014 年双十一的进度，时间非常紧张。上“双十一”，就意味着在线上不能出一次问题，那时有大约近二十万行代码是半年之内一次性新开发的，但是上线不能出一次问题，因此对质量保证提出特别严格的要求。上线前做了很多容灾测试、代码检测、设计检测等，包括当时涉及到的所有 SQL 语句都做了全面测试。“即便是这些事情都做了，也还是有一定的运气成分，最后 OceanBase 上线没有出一次故障。因为当时七八月份对核心业务底层系统升级完后就不可能再升级了，后面确实一个问题都没有出现，最后双十一成功切了 10%的流量。”如果当时出现哪怕一次问题，可能 OceanBase 将不再存在。

▌在蚂蚁，遇到更好的自己

2014 年的时候，OceanBase 团队面临着当年双十一的生死大考。而冯柯也是在 2014 年加入 OceanBase 团队的，作为一个传统技术和商业环境出身的技术人员，冯柯在 OceanBase 经历了从传统企业文化到互联网公司文化的转型。

“我那时有很强的思维惯性，刚来 OceanBase 的时候，觉得看什么都不爽，OceanBase 是别人写的代码，总觉得这里不应该这样做，那里不应该那样做。那个时候特别挑战，也包括过去是我说了算，今天说了不算，反正是非常痛苦的一个过程。”冯柯来 OceanBase 前半年基本上处于每天无事可干的状态，后来主管就给他布置任务，让他放下层级的观念去把 OceanBase 源代码看一遍。于是，冯柯当时就用了大概 6 个月左右的时间，看了将近 20 万行、每个月 5 万行左右的代码，报了 100 多个 bug，写了很多文档，做了最基础的事情。

这个过程让冯柯在从代码上更了解 OceanBase，能够做更具体的事情，其次也是最重要的就是调整了心态。“我刚加入蚂蚁金服的时候觉得很恐惧，觉得阿里是一个价值观很强的公司，后来发现层级只是对你过去的一个认可，来了阿里之后就要忘了过去，从头开始。把自己沉下去，再浮上来，你就会更加有力量。”当从代码上真正认可了 OceanBase，把 OceanBase 当作自己的产品，就能把自己全部投入到 OceanBase 中。“现在看两年前的我，确实变化比较大。来了阿里之后，遇见更好的自己。”

之所以说到阿里之后遇见更好的自己，这首先是要放开自己、重新清零，打破思维定势后就能给团队带来非常大的帮助。冯柯发现蚂蚁金服的团队文化不像国企那样层级就代表决定权，在蚂蚁金服必须要做事情、真正拿到结果并获得大家的认可和信任，才能做更多的事情。“大家并没有去想你是一个 P10 或 P9，你不应该做这个事，你应该做那个事，这是我特别感触的一点。蚂蚁金服真的是一个非常专注技术、完全内部平等的文化，这跟我在之前的很多公司差别很大。”而这，正是在阿里遇到更好的自己的原因所在。

▌OceanBase 商业化：再创造新时代

“OceanBase 是真正想去做一款通用的分布式数据库产品。产品化这点非常重要，这就要对用户做高度集成的整体交付，而不是一堆技术拼起来。OceanBase 在架构上是真正想去做一款能够改变目前整个商业数据库生态或者格局的产品，我不管它未来能不能做到，但当时非常打动我，也是吸引我加入 OceanBase 的原因。” 冯柯说：“分布式是 OceanBase 的亮点，但最重要的是 OceanBase 是按照产品的思维而不是单纯解决业务的问题，当时我就看明白了，OceanBase 未来肯定是要到外部发展。”

关系数据库这个领域的理论已经比较早就成型了，多年来也没有突破性的进展。而 OceanBase 这些年做的事情，其实是在做一个分布式的关系数据库产品。在做产品的过程中，最大的问题是要有特别好的场景来检验它，从而演变成一个能够商业化的产品。蚂蚁金服最大的优势是业务场景非常丰富，让 OceanBase 在服务外部客户之前，就在内部得到非常充分的锻炼，而这些锻炼很难通过外部用户去获得。

蒋志勇强调，数据库产品化需要时间去历练，如果抱着非常投机的心态参与就很难实现。“所以从业人员要确实对这个有兴趣，并且要愿意长时间坚守、慢慢打磨，把 OceanBase 从几个人做出来的软件，变成一个很好用的通用产品。”

从 2017 年开始，OceanBase 跟随整个蚂蚁金服的金融科技开放，开始了向传统金融赋能的实践过程。当然，这个过程也不是一帆风顺。虽然 OceanBase 已经取得了很大的技术成就，但在外部用户应用 OceanBase 的过程中，往往会被很多具体的小细节所“绊倒”。现在负责 OceanBase 外部业务的冯柯表示，外部客户往往没有蚂蚁金服这么成熟的技术体系，还处于各种传统技术混搭的局面，在这种情况下如何把 OceanBase 在外部用户的业务环境中落地，这都是需要具体解决的问题。

OceanBase 终于迈出了商用的一小步：OceanBase 在南京银行正式上线，OceanBase 数据库为南京银行“鑫云+”互联网金融开放平台提供金融级分布式关系数据库服务。而这主要取决于南京银行的意愿，“南京银行自身有非常强的意愿和情怀，把整个互联网的核心业务完全架到 OceanBase 之上。南京银行就像蚂蚁金服内部的业务方一样，真正与技术团队站在了一起，包括南京银行的很多设计都是超前的，即使目前的业务量不需要这样设计的也会提前布局，后面有一个非常长远的规划。南京银行项目为什么成功，就是因为这一点。” 冯柯总结南京银行的成功。“南京银行当时是阳振坤老师去谈的，南京银行也有竞标，也不只蚂蚁金服一家。当时南京银行技术负责人问了阳老师一句话，你们到底有没有决心替换掉 Oracle，这句话撞到阳老师的枪口上了。”

阳振坤回忆 OceanBase 的整个发展历程，“首先肯定是要满足内部的业务需求，如果连自己的需求都满足不了，就根本谈不上做成一个真正的商用数据库。也许 Google 吃亏在他们的业务部门比较强势了，所以做出来的 Google Spanner 就是一个满足自己内部需求的产品，所有的都是自定义。而 OceanBase 走了一条标准化之路，我们支持标准的数据库接口、标准的数据库语言，所以能够产品化。”

从 2010 年 5 月调研、6 月 25 日立项开始，OceanBase 的目标就是传统商业关系数据库的更新换代产品：2012 年底支持简单的 SQL；2014 年支持比较有限的 SQL；2016 年基本兼容了 MySQL，对 SQL 的支持开始丰富起来。这是一个由分布式到与数据库结合的过程。接下来，OceanBase 要兼容商业数据库。再接下来，就是要发展 OLAP 技术。

与 OLTP 技术的要求不同，OLAP 偏向大型数据分析，对于查询处理、计划生成、性能和调度等的要求非常高，对于分布式集群的大型查询，怎样通过调度把负载分配到每一个合适的节点，让整体的吞吐率和响应时间都能达到一个比较好的平衡，都需要大量的工作。

总结 OceanBase 的成功，可以说是阿里巴巴/蚂蚁金服举全集团之力完成的“壮举”。用杨传辉的话说，就是阿里对技术容忍度超乎想象的高。马云经常讲：我不懂技术，但是我尊重技术。

阳振坤回顾 OceanBase 的内部创业史，对于数据库技术来说在蚂蚁金服内部创业要远比在公司外部创业好，因为根本找不到像蚂蚁金服这样愿意把自己的内部业务拿出来当“小白鼠”。“我觉得我们这些人正好赶上了一个很好的机会，所以我就跟大家说这是千载难逢的机会，我们一定要做，而且一定能做成。”