“去IOE”激战9年：深度揭秘OceanBase如何异军突起

近十年，随着云计算带来的变革，传统的 IOE 架构对于企业运营成本的影响以及对未来业务发展的制约逐渐加剧。

尤其是互联网的大规模、高并发、实时在线、大型网络优化等新兴需求，使得为传统 IT 环境设计的 Oracle 数据库越来越难以处理互联网公司愈加大规模的数据量。

因此，面向超大规模互联网公司的分布式计算环境而重新开发的关系型数据库 OceanBase 应运而生。

作为蚂蚁金服自研的分布式关系型数据库，OceanBase 从 2008 年阿里提出“去IOE”想法，到 2017 年蚂蚁金服全面实现“去IOE”，经历过许多难以想象的磨砺，也创下了许多影响国内外的成就。

本文将深入 OceanBase，回溯其研发过程与研发方法论。

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

以下仅摘选几个典型案例作为说明：

结合业务，整体优化软硬件

蚂蚁金服基础数据部（OceanBase 团队）负责 SQL 相关方向开发工作的陈萌萌介绍说，以前数据库技术更多偏向软件层，硬件层有专业人员、专业技术和专业的公司来解决硬件本身的稳定性或容灾等问题。

但是在蚂蚁金服这边更多是软硬结合的方案，OceanBase 软件从设计之初就考虑了硬件层面不稳定、分布式系统的特征，从而去做以前数据库不会做的优化工作。

以前的数据库优化根本不会考虑到底层的硬件损坏、机器宕掉、网络断网、天灾人祸不确定性问题，而今天 OceanBase 无时无刻不在考虑这些问题。

“以前做软件开发，先假设底层的硬件没有问题，而只需要把上层软件逻辑做好就行了，现在我们是整体的软硬件考虑。”

以数据库的查询优化技术来讲，比如传统的银行柜台，通过人工窗口提供服务，用户的主要时间花在与人工窗口打交道等方面，对于数据库的快慢体会不那么敏感。

但蚂蚁金服是互联网应用，数据库随时的一个抖动或查询执行时间变慢了一点，用户马上就能直接感受到。

这与传统应用场景差异很大，如果数据库的一个查询从一毫秒变到了五毫秒，传统数据库不会认为这是件大事。

但是互联网应用下，多出来的四毫秒可能被放大成为几百毫秒甚至一两秒，一旦出现这样的时延，用户体验马上就变差了。

“我们每天都在做特别精细的事情，生怕一毫秒变成五毫秒这种事情出现，因此做了很多精确防御。”

蚂蚁金服基础数据部（OceanBase 团队）研究员杨传辉进一步解释：数据库查询优化器本身是近似解，基本上不存在最优解，优化的目标就是逼近最理想的情况。

在传统应用场景下可以允许优化结果差几个毫秒甚至更多，但是在互联网场景下就很难接受这么大的差异，所有的优化效果都要精确到几个毫秒以内。

例如：每一次在支付宝付款，点击一下付款按钮，背后的数据库可能要执行一两百次数据库的 SQL 查询，优化器要为每一个查询生成一个需要做的优化执行计划。

如果优化器在某一个场景下犯了一个错误，每个查询多出了 5 毫秒，那么整个链路就会多 500 毫秒，用户在按下付款按钮的时候发现交互速度有可能变慢了。

如果再加上可能不止做支付——比如买商品后下单再要支付——这几个链路加在一起就有可能慢几百毫秒甚至上到秒级，这对用户来说就已经不能接受了。

还有地铁的刷脸或者刷支付宝进站的场景。如果用户站在闸机前面半天刷不出来，那就不光是体验问题了，有可能会引来连锁麻烦，后面人也会被堵起长龙。这些现实的挑战都要求 OceanBase 反应精确、迅速。

杨传辉告诉我们，从关键业务系统的数据链路梳理上来看，一两百条 SQL 是最普通的一次交易了，如果涉及到支付渠道不一样，SQL 执行的次数就会更多。

因为蚂蚁金服本身是分布式的系统，所面临一个很大的挑战是对底层的基础组件包括网络要求非常高。

如果网络出现了问题，就会对整个服务产生影响。因此 OceanBase 不仅要对数据库层做优化，还对网络、磁盘、操作系统等软硬件层都要做很精确的优化。

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

蚂蚁金服基础数据部（OceanBase 团队）SQL 组负责人蒋志勇从事 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 系统 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 个人去看监控就会得出 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 是软件、硬件和业务集成在一起的整体优化，而当软件、硬件和业务碰到一起的时候，经常会出现各种碎片化的小场景问题，那么又是怎么解决的呢？

陈萌萌介绍说，当遇到这样的场景时，就会提前把大家拉到一个群里，把需求丢到群中，技术团队根据需求提供反馈建议，业务团队也会反馈在试验中遇到的问题。

这些碎片化的场景和问题，很难区分到是软件、硬件还是业务的问题，因此群里有运维、开发、业务甚至还有负责业务拓展的 BD 和负责产品的 PD，只要需要关注的人员都可以进到群里。

每个人有负责的业务或技术方向，空闲的时间就会把群里的来龙去脉都过一遍。

有些群是按需找人，在群里被 @ 了就肯定会关注这些消息，如果没有被 @，就会找不是特别紧急时候再把群里的消息过一遍。

虽然群很多，但是真正过群消息的时候，几分钟时间还是能够把过去几天的消息都过一遍。这样总是能区分哪些是需要第一时间响应的，哪些可以后续持续关注的。

一般 OceanBase 团队的工作时间是早 9 点到晚 9 点 12 个小时，但也有大促的“双十一”、“6.18”、春节红包压测等紧急情况。

当然，随着 OceanBase 的发展，需要处理紧急事件的情况在减少。陈萌萌回忆，以前跟着业务团队压测到凌晨，甚至说半夜被揪起来的情况，会经常发生。

“我记得经历过很多故障都挺戏剧化的。因为一旦出现一些问题以后，各方面的人都会被半夜拉起来，大家临时被拉到一个群里面，谁也不知道当时发生了什么。但是每个人可能有一部分的信息，大家很快把各自的信息扔到群里面，这样就对出来到底发生了什么。每个人都有点胆战心惊，生怕自己做的那部分导致了什么问题。”

陈萌萌回忆说：“我记得有一次故障，半夜 11 点说有一个问题需要大家上线去看，一帮人包括主管都上线看问题，一直到凌晨四五点。一开始大家都在，慢慢发现问题越来越聚焦，相关的人员就上来，一直到凌晨四五点才解决问题。中间大家在群里面各种排查信息分析，提出各种建议，虽然没有坐在一起，但就像关在一个屋子里面开了连夜的战斗会一样。”

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

当然，群里也会有熟悉各种“疑难杂症”的“老中医”，一般是经验比较丰富的人员，见到的问题也比较多。

所以别人可能还在猜测的时候，“老中医”就会给一个很靠谱的可能性，沿着这个可能性去看的话，发现确实可以通过这个角度去挖掘解决问题的方案。

然而，即使讨论出了可能的解决方案，“大家还是挺胆战心惊的，敲命令都是让专门负责运维的人员去敲，这个时候的关键在于手不抖、别敲错，因为万一敲错了那就是二次故障。所以我们都会找一个心理素质好的同事操作，大家谁也不要吱声，看着这个同事安静地把命令敲完。”

因为不管通过群里的讨论，选择一条最保险最靠谱的操作方式，但在系统里面直接敲命令都有可能直接动数据，敲错一个键就有可能把所有数据都删了，这是没法挽回的，“所有人在操作的时候都不敢出气”。

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

整个 OceanBase 并没有一个统一的产品经理，因为 OceanBase 的功能列表是对标商业数据库。

但还是会有产品开发的规划，通常以财年为单位、双十一为重要节点，比如某个版本必须要在下一个双十一之前做出来并且稳定运行，再通过双十一检验。“保持这样一个节奏”，蒋志勇补充。

未来展望：用时间历练、用现实考验

蒋志勇强调，数据库产品化需要时间去历练，如果抱着投机的心态参与就很难实现。

蚂蚁金服最大的优势是业务场景非常丰富，让 OceanBase 在服务外部客户之前，就在内部得到充分锻炼，而这些锻炼很难通过外部用户去获得。

从 2017 年开始，OceanBase 跟随整个蚂蚁金服的金融科技开放，开始了向传统金融赋能的实践过程。

负责 OceanBase 外部业务的冯柯表示：“分布式是 OceanBase 的亮点，但最重要的是 OceanBase 是按照产品的思维而不是单纯解决业务的问题，未来肯定是要到外部发展。”

如今，OceanBase 已从金融级分布式关系数据库服务为起点，迈出了商用的一小步。

承受住时间的历练和现实的考验后，团队有信心将 OceanBase 从一个软件变成一款通用产品。

作者：吴宁川