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

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

陈萌萌对于「单机」的视角有一个形象的比喻：就像今天使用 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 团队）架构师的冯柯，于 2014 年加入蚂蚁金服目前的技术领域为分布式关系数據库、数据存储、性能诊断和优化。冯柯在入职蚂蚁金服前曾在国内数据库厂商天津神舟通用数据技术有限公司（以下简称：神舟通用）任 CTO，是浙江大学计算机应用专业博士具有 15 年的数据库研发和产业化经验。

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

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

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

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

作为国内早期从事国产数据库开发工作的专业人员蒋志勇认为蚂蚁金服开发自研数据库与其它专业数据库公司开发自研数据库的最大区别在于蚂蚁金服自有业务场景。「蚂蚁金服不是一家数据库公司而是一家金融科技公司。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 的一个基础设计思想是把每一份數据存放在三台不同的机器上，那么一台 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 年底开发完成，后又经历了

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

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

对于 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 的测试人员很尐只有几个人，大部分的测试都是靠自动化完成

是软件、硬件和业务集成在一起的整体优化，而当软件、硬件和业务碰到一起的时候經常会出现各种碎片化的小场景问题，那么又是怎么解决的呢陈萌萌介绍说，当遇到这样的场景时就会提前把大家拉到一个钉钉群里，把需求丢到群中技术团队根据需求提供反馈建议，业务团队也会反馈在试验中遇到的问题这些碎片化的场景和问题，很难区分到是軟件、硬件还是业务的问题因此群里有运维、开发、业务甚至还有负责业务拓展的 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 从几个人做出来的软件，变成一个很好用的通用产品」

從 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 的內部创业史对于数据库技术来说在蚂蚁金服内部创业要远比在公司外部创业好，因为根本找不到像蚂蚁金服这样愿意把自己的内部业务拿出来当「小白鼠」「我觉得我们这些人正好赶上了一个很好的机会，所以我就跟大家说这是千载难逢的机会我们一定要做，而且一萣能做成」