蚂蚁金服自研数据库OceanBase的前世今生：从濒临解散到浴火重生

数据库在每个人的生活里无处不在，不管是通讯、交通、金融行业，抑或是每天大家都在接触的互联网，所有这些业务的背后都是数据库在支撑。

蚂蚁金服 OceanBase 团队负责人阳振坤

数据库经历了近半个世纪的发展，在理论上很成熟，在技术应用上也已经非常成熟了。但是数据库偏偏有一个特别高的门槛，原因是数据库有三条特别苛刻的要求：

1. 事务须并发处理： 数据库要支持事务，所有人都希望用最小的处理资源，做到最大价值的事情。所以事务持续要做大量的并发处理。

2. 数据一条不能错： 一个数据库如果数据错了，就永远没有机会了。对于使用者而言，如果你会错一条，你就有可能会错一千、一万条，这是没有公司愿意承担的风险。

3. 服务片刻不能停： 通讯系统、列车系统，甚至飞机航行系统的背后都是数据库在支撑，这些系统一旦启动，一分一秒都是不能终止的。

上面提到的这三条要求，任何两个其实都好满足。但是大家仔细想一想，这三个要求如果要同时满足，就会变得极其困难。

同时，数据库又是一个巨大的市场，对国家、对整个社会都非常重要。这就导致很多国家、很多企业都想做也正在做这件事，但是结果大家都做到了同一个思路上。后来者都成了先行者的模仿者，那么这个模仿的代价就会变得很大。

今天作为一个后来者，你再去做这么一套数据库系统的时候，就真的很难说清楚你与先行者相比有多大的优势。这也就造成了强者恒强、寡头垄断的局面，后来者很难居上。

数据库同样也有开源这条路径，比如大家都了解的 MySQL。开源是免费的，对于很多对成本敏感的公司而言开源数据库成为了替代商业数据库的另一种选择。

那么在面对数据库的“死亡之谷”这样的困境下，为什么我们还去花这么多钱，投入这么多设备，花这么多年时间和人力再去做一个数据库，究竟它的意义在哪儿？它又能够产生多大的经济价值？

既然有了开源的数据库，阿里巴巴和蚂蚁金服还要做这么一个商业数据库产品，其实这里面是有本质原因的。很多人知道阿里巴巴今天已经 全面去 IOE：去掉了 Oracle 数据库、IBM 小型机、 EMC 存储。那么很多人就在想，能不能在其他的行业，在铁路、交通，电信、政府这些行业推而广之，全部完成去 O 的进程呢？这个答案是否定的。

因为像阿里巴巴发展的这一套系统是基于 MySQL 的开源数据库，跟商业数据库在功能和性能上其实是有很大差距的。阿里巴巴当时在用它的时候，有很多事情数据库是做不了的，那么这些做不了的事情当时就放在应用软件里做。所以阿里巴巴在数据库和应用软件上都投入了很大的技术力量。这套系统拿到外部业务去用是不能彻底解决问题的。本质上这套系统是服务于阿里巴巴的专用系统，而不是一个通用的系统。

那么有人会问，在我的企业里，如果真的想去掉 IOE，该怎么办？你同样要投入两拨人，一拨人要去做数据库，针对你的企业的需求来做相应的修改；还有一拨人要去做应用系统。但是问题是并不是所有的企业都像阿里巴巴有这么多优秀的技术人员，这套东西其实很难去直接推广应用。

所以，从一开始我们做 OceanBase 的目标就是——我们不想只做一个专用的系统，要做就一定要做一个通用的系统。我们希望今后 OceanBase 能够服务于各行各业，再也不需要企业投入几十几百甚至几千个人去改造、去重新做一套业务系统。

当时做 OceanBase 数据库一个最根本性的原因就是需求的变化。因为这么一套基础系统，如果背后没有需求的变化，从 0 到 1 自己做出来基本是不可能的。

2010 年春夏之际，我来到了阿里巴巴。去了之后发现当时有两个因素影响了阿里巴巴关系数据库的应用。

一个因素是并发，数据库它是按照并发量来卖钱的。说直接点，就是按照处理器来卖钱。之所以要买这么多处理器就是因为业务有这么大的需求。那么传统的业务比如商场，一个商场就那么几个收银台，它是一个相对稳定而且比较小的并发量，大多数情况就是几十几百的并发量。

阳振坤分享经验心得

随着互联网的高速发展，阿里巴巴天猫双 11 几乎完全改变了过去行业内相对稳定的并发量，突破了几百万人甚至是千万人的同时在线购买。这个并发量跟过去的传统业务场景相比是几个数量级的增长，按照这个数量级去买商业数据库，没有一家企业买得起。

还有一个因素，当时我们叫它建站，其实就是搭建一个数据库。过去建一个商场，建一个银行的分店，这个周期是非常长的，有足够的时间来规划 IT 业务系统。互联网业务是等不了的，就像当时 OceanBase 接的第一个业务给到我们的时间就是最多一个星期。现实是一个星期的时间根本连小型机的安装调试都完不成。

原来的模式已经完全无法支撑互联网快速发展的业务。所以这两个需求的变化，是催生我们自己来做数据库的很关键的因素。

当时我找了几个同事商量这个事情，我跟大家说，我们是天时地利人和都赶上，这件事情除非是被拍死掉，否则我们是肯定要把它做成的。这个过程真的非常艰辛，我们花了差不多五年的时间，才真正让 OceanBase 有了关键的应用。

过去做数据库的公司，不管是国内还是国外，大家都是为了做数据库而做数据库，那么最后结果就是所有做传统数据库的厂商，大家的方案都很像。

因为数据库有很成熟的理论和工程的方法，那么如果我们按照以往的原则做过去，结果肯定也是一样的。所以，其实我们走了另外一条路——做分布式。最早做这个东西可能都不叫数据库，它更像是一个分布式系统，但是支持了事务的特性。这条路后来被证明确实是具有特别大的价值和意义。

当时我们在做 OceanBase 的时候，首先确定了几件事情。第一件事就是我们要做分布式，因为我们的业务要建站，不做分布式靠大型机和小型机是不可能做得到的。

另外一件事是成本，什么东西最便宜，量最大最主流的东西最便宜，它就是 PC 服务器。小型机少则几十万，多则几百万，PC 服务器顶多就是几千几万块的成本。

第三个要解决的就是可靠性问题。大家对数据库的期望是永不宕机，永远不出问题。可是 PC 服务器到处都有，性价比也非常好，但是不容忽视的是它的故障率高。普通 PC 服务器它远远达不到数据库所要求的年可靠性五个九的要求。对普通 PC 服务器而言，差的可能是两个或者三个数量级，所以我们得首先把这个问题解决掉。我们用的就是分布式的办法来解决。

我们运用的是分布式的一致性协议，直白一点就是一个多数派的选举和投票协议。同时，我们把修改的增量直接放在内存里，每次要查询的时候，把内存硬盘的数据做一个 merge，那么每天在业务相对的低谷期，再把内存中的数据整理回硬盘去。

做到了这几件事情，这个系统就有了很好的性价比，我们的成本比传统的数据库至少低一个数量级，你只需要用普通的 PC 机，不需要用昂贵的硬件设施。同时，扩展能力会也变得很好。

理想看起来很美好，但是现实特别骨感。这个项目刚启动的时候，我们好不容易才找到了几个人，人手是严重不足的。另外一个更大的挑战是时间：在做 OceanBase 数据库之前，我去找我的老板，他说给你 两年时间 如果能把一个数据库做出来就可以。当时我心里想两年虽然对于做数据库来说时间确实太短，但是这两年对于那时候的我们而言已经足够支撑起最初的想法了。

技术最终还是需要通过业务落实下去，所以我找了一批业务方，花了很长时间跟对方沟通，最后终于有一个业务愿意用我们的数据库。当时他给我的时间期限是——两个星期。

当时我就傻了，两个星期要做个数据库，这可怎么办？后来跟业务的同学反复讨论，最后他们同意说，你们先做个 demo 出来。于是我们就花了两个月吭哧吭哧的做了一个 demo 出来。他们看了以后觉得比较满意，后来这个事情就一直坚持做下去了。

最后，我记得是到了第八个月的时候，系统上线了。这个业务就是现在大家都在用的——淘宝收藏夹，这是 OceanBase 的第一个业务。如果没有这个业务，我们现在也活不下来。

淘宝收藏夹业务

那么这个业务到底有什么特殊的地方？每个人都用过淘宝收藏夹，每次你打开收藏夹的时候，数据库在背后其实做了很多事情：我们以单个商品为例，它需要到一个叫商品库的地方，逐条纪录核对，看看商品有没有下架，有没有参与促销，有没有参加其他的返点活动等等。

假如你收藏了 100 多件商品，它就要进去一条条的取出来看。本质上来讲，这就意味着一百多次的随机 IO。那么当很多人同时来看的时候，其实一个 IO 就被放大了几百倍，这时候有多少个硬盘都不够用。

当时他们已经用了几十台服务器了，按照业务的预估，第二年他们要买 400 台机器，第三年的数量都不敢想象。当时我们想了一个办法——我们做了一个 宽表，确切的讲应该称为 物化视图。

淘宝收藏夹的宽表

首先我们把每个用户收藏的信息聚集起来，这样可以减少 IO，然后把收藏的商品放在这个列表里。但是我们怎么避免去访问一百多次 IO 呢？我们的办法就是找到一个时间点，当时是设定在每天晚上凌晨两点。在这之前，我们就把这些信息全部 merge 到硬盘，然后从两点开始，我们把新的修改都放在内存里面。

所以每到两点的时候，我们把两点之前所有的信息都合到这张表里，那么这张表里的信息在两点整的时候是准确的，这时候我们不需要去访问商品库。两点之后的修改，包括商品库的修改是在内存里进行的，这时候如果要看这些商品有哪些修改，商品只需访问内存中的更新即可。

所以其实我们就是通过这样一个手段，把每次收藏夹的展示，由原来的一百多次 IO 变成了一次。我们一下子就把淘宝收藏夹业务的整个 IO 降下来了。当时 OceanBase 确实是帮助业务实际解决了他们的问题，使得业务能够更好的快速的发展。业务是一定要发展的，所以只有我们真正能够解决他们的问题，我们这些做基础系统做底层的人，才能活下去。

淘宝收藏夹架构图

这是当时给淘宝收藏夹做的一个架构，中间是一个做修改的服务器，所有的修改都在这一台机器上进行。旁边的机器是基线数据，就是分片切片以后，放到周围这一圈进行。所以当时我们就用这个看上去很简陋的一个方案来真正解决了淘宝收藏夹的问题。

当时收藏夹用了这个方案之后，服务器的数量从原来预计的第二年要用几百台，最后其实只用了差不多二十几台服务器，就把整个问题解决掉了。

从淘宝收藏夹项目之后，我们陆陆续续也做了不少项目，但是没有一个项目能像淘宝收藏夹这样对业务有明显的价值和贡献。

从那之后的整整两年，我们找不到对 OceanBase 数据库而言特别有价值的业务。那两年对于我们而言特别特别困难，甚至整个团队随时面临着解散。

2012 年底，公司把我们从淘宝调到支付宝，当时预估到支付宝在数据库方面所面对的挑战更大，后来证明确实如此。即使是这样，当时仍然还处在一个非常困难的时期。到了支付宝一年多的时间，我们仍然很难找到新的业务，或者说价值比较大的业务来证明我们的价值。

2013 年的夏天，支付宝希望全面去掉 IOE——去掉 IBM 的小型机，Oracle 的数据库和 EMC 的存储。当时面临了一个问题，就是去掉之后是可以用 MySQL 来代替 Oracle，但是 MySQL 的主备镜像其实是做不到主备完全一致的。

这个时候我们意识到：OceanBase 的机会来了。因为我们可以通过分布式的选举跟投票来做，哪怕硬件本身不可靠，我们也能保证数据的不丢失。传统数据库本质上是借助硬件的可靠性，也就是硬件需要达到五个九的可靠性来实现高可用的。就算出了故障，它的数据也能救得回来。但是这种手段需要非常高的成本，同时没有足够的扩展能力。

银行虽然有很高的可用性，但是它的高可用性是用很高的硬件成本换来的。我们建议一定要淘汰这些高可靠的硬件，因为他们的成本实在太高了。一旦真的使用了高性能，高性价比的 PC 服务器，那么你就不可能再花那么多钱去买高端的硬件。

所以我当时心里很明白，如果这件事情我们做不成，这个项目就只有死路一条。

那么，OceanBase 到底如何做到主备完全一致的呢？理论上我们也没有办法说完全做到主库备库的一致。我们用了另外一个办法：主库还是主库，还是需要它快速的做事务，但同时主库还要把事务的日志同步给至少两个备库。两个备库中至少有一个收到了，那么加上它自己就超过了半数，或者我们叫多数派。当多数的节点收到了这个事务，并且把它持久化到硬盘了，我们就认为这个事务是成功的。

所以这时候任何一台机器坏掉，每笔事务在剩下两台机器里面至少一台存在。所以说即使主库突然坏掉，另外两台机器经过握手，它们再选举出一个新的主库，那么肯定可以继续工作下去，同时可以保证数据是没有损失的。

2014 年的时候，我们在会议室里讨论 支付宝交易库的上线，当时吵得面红耳赤，争论了很久别人就是不愿意上 OB。他们原来的交易、支付系统全都在 Oracle 上，当时的 Oracle 无论是在稳定性、可靠性还是性能方面，肯定比 OceanBase 要好得多。所以没有人愿意用。

最后，在 鲁肃（蚂蚁金服 CTO） 的力挺下决定切给 OceanBase 1% 的流量试试。因为那几年业务发展的太快，当时 Oracle 的共享存储已经扛不住这个流量，按照当时的业务流量去做压测的时候，几分钟就要坏一块盘。最后发现，把业务切掉 10%，才能勉强扛得住。所以那一年的双 11 就把 10% 的流量切到了 OceanBase。OceanBase 也成功扛过去了那一年的双 11。

但是其实在 0.5 这个版本上线的时候，我们心里非常清楚，这个版本是临时的。我们当时选择做多数派协议的时候，还是用了原来的想法，每个集群还是中间有一个中心节点。这个事情一定不会是长久持续下去的，我们知道这个一定会遇到问题。所以当时其实交易库还没有完全上线，我们就已经启动了 1.0 版本的开发。

2014 年到 2016 年，整整两年的时间，我们投入了 40 多个人，全部投在 OceanBase 1.0 版本的开发上。整整两年，这 40 多个人没干任何别的事情。所有的线上问题，版本修改、升级都是我们调出来的五个同学全部扛下来的。

有人会问什么样的因素让这么多人做了两年才能把这个版本做出来？这个版本里面我们主要做的一件事就是分布式。

如果你问分布式事务有这么难吗？我可以自豪地回答你：今天的商业数据库里有且只有一个是能够支持分布式事务的，它就是 OceanBase。

OceanBase 通过分布式的一致性协议做到了系统的高可用性，就是说哪怕我们今天用的是比较廉价的，可靠性比较低的 PC 服务器，但是我们的可用性其实会变得更高。因为单机的故障我们完全能够自动的容忍掉，而且我们做到了现在的数据做不到的一件事情——哪怕主库出故障，我们能够保证数据没有任何损失。

今天的银行每年国家都要求他们至少做一次消防演习，银行要到最前端的网关把交易纪录捞出来核对，把这些账对平了，备库才能继续服务。我们今天根本没有这个问题，主库出故障了，也就是几十秒以后，新的主库就会被选出来。因为只要剩下的机器超过半数，他们互相之间会通过握手把数据补齐，很快就能工作。其实这 30 秒大部分还是消耗在确定主库是否真的有故障。

所以，我们用不可靠的硬件反而做到了更高的可用性，而且做到了数据真正的一致。

传统的数据库因为涉及到共享存储，共享存储是一个单一的设备，你只能放在一个机房。所以一旦那个机房出现了故障，你就只能靠备库容灾把系统恢复起来。

OceanBase 通过“三地五中心”部署实现城市级故障自动无损容灾。比方说相当于你一共写了五份日志，放在三个不同的城市里。任何一个城市哪怕出故障，比方说杭州断网了，那么剩下的依然超过半数，这个系统还是可以恢复工作的。这也是原来的传统数据库，不管想什么办法，都做不到的事情。

9 月 20 日云栖大会 ATEC 主论坛现场剪光缆实况

前段时间，大家可能也看到了云栖大会的新闻。蚂蚁金服副 CTO 胡喜在 ATEC 主论坛现场模拟挖断支付宝近一半服务器的光缆。结果只过了 26 秒，模拟环境中的支付宝就完全恢复了正常。而这场 26 秒自断服务器现场演示的技术核心其实正是基于 OceanBase 的三地五中心架构方案。

2017 年，天猫双 11 中蚂蚁金服的全部核心系统，包括很多业务系统都放在了 OceanBase 上。去年我们创造了 25.6 万笔 / 秒 支付峰值的世界纪录，这下面还有一个数据，就是说我们为了要执行这 25.6 万笔的支付，执行了 4200 万条 SQL。

所以从今天来看，OceanBase 在过去的历史进程中面临了一个个新的机遇，无论是处理器、操作系统还是数据库，这些都是非常大的挑战。

从 2016 年底，我们就开始做准备，OceanBase 一定要走出去。从我们成立的第一天起，团队里的每个成员的目标都是一致的：我们不是想做一个数据库只是给自己用，我们要做一个数据库真的去推动整个社会的进步，能够让整个社会的生产力发生变化。

所以，2017 年我们正式开始服务于外部，最早的两家客户是 浙商银行 和 南京银行，我们现在的客户要多很多。从内部的应用到真正走出去服务于外部，真的是一个很大的挑战，是一件很困难的事情。

回想这八年多来，OceanBase 走过的路：开始的头两三年，我们真的每天都在挣扎，每分每秒都在想着怎么能让自己活下来。到了 2013、2014 年，我们终于找到了一个真正的立足点，就是支付宝的交易库。然后我们接着花了整整两年的时间，真正在 OceanBase 1.0 版本把分布式做出来。在接下来的一到两年时间里，我们把支付宝的核心业务全部搬到 OceanBase 上。

关系数据库确实是个门槛很高的东西，但是凡事有利有弊。门槛高意味着我们进来很难，别人进来一样难。我们集中精力在做事务处理这一块，它的门槛是很高，很不容易进去，但我们恰恰有这个机会能进去。我们费了很大的力气跨进来了，别人可能费了全部力气也进不来。

现在回想起来，能够把最早的一些想法一些创新变成产品，真的是非常辛苦或者说非常痛苦的一条道路。但是我们做的所有事情其实还是从业务、从客户中出发，只有技术真的能够落到生产中去，落到用户中去才是真正有价值的，否则你做得再好也是一个空中楼阁。

到了今天，当我们走出阿里巴巴，走出蚂蚁金服再来看，发现 当你做的事情能够提供十倍性价比的时候，其实真的有机会去颠覆一个产业，重新塑造一个行业。

OceanBase 是由蚂蚁金服、阿里巴巴完全自主研发的金融级分布式关系数据库，始创于 2010 年。OceanBase 对传统的关系数据库进行了开创性的革新。在普通硬件上实现金融级高可用，在金融行业首创“三地五中心”城市级故障自动无损容灾新标准，同时具备在线水平扩展能力。在 2017 年天猫双 11 中创造了 4200 万次 / 秒处理峰值的世界纪录。在刚刚结束的 2018 年天猫双 11 中，OceanBase 2.0 版本支撑了支付宝的核心链路，性能比去年提升了 50%，真正实现了“零成本”支撑大促。欢迎关注“OceanBase”公众号，了解更多数据库干货，破解今年天猫双 11 突破 2135 亿元成交额背后的技术密码。