技术成就：划时代的分布式数据库
通过核心业务的不断上线，蚂蚁金服帮助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是软件、硬件和业务集成在一起的整体优化，而当软件、硬件和业务碰到一起的时候，经常会出现各种碎片化的小场景问题，那么又是怎么解决的呢？陈萌萌介绍说，当遇到这样的场景时，就会提前把大家拉到一个钉钉群里，把需求丢到群中，技术团队根据需求提供反馈建议，业务团队也会反馈在试验中遇到的问题。这些碎片化的场景和问题，很难区分到是软件、硬件还是业务的问题，因此群里有运维、开发、业务甚至还有负责业务拓展的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的内部创业史，对于数据库技术来说在蚂蚁金服内部创业要远比在公司外部创业好，因为根本找不到像蚂蚁金服这样愿意把自己的内部业务拿出来当“小白鼠”。“我觉得我们这些人正好赶上了一个很好的机会，所以我就跟大家说这是千载难逢的机会，我们一定要做，而且一定能做成。”
本文作者：安和林
详情请阅读原文