蚂蚁金服P11，用10年时间打造支付宝背后的OceanBase！

2009年开始，大量新的非关系型数据库如雨后春笋般涌出，在整个数据库行业掀起了一场空前盛大的NoSQL革命。这时候的关系数据库早已过了而立之年，在此期间虽然曾短暂爆发过一些所谓终结关系数据库的革命，但丝毫没有动摇到关系数据库的主导地位。

但这一次似乎与以往不同，火热发展的云计算带来了对更大规模数据库的需求，而关系数据库的缺点则相应地被越来越多人诟病： 不能够扩展、容量小、处理能力不够、成本又非常高 。

在当时的很多人看来，关系数据库的末日是真的要来了。

那时阳振坤已经在百度做了两年多的自研分布式系统。百度数以万亿计的网页意味着与日俱增的天量数据，阳振坤十分看好云计算系统的发展机会。同一年，阳振坤离开百度，加入阿里巴巴，就在上面这篇文章发出的 2 个月之后，开始了分布式关系数据库 OceanBase 的研发。

OceanBase的第一个客户来自淘宝收藏夹。

当时的淘宝收藏夹正处于业务高速发展期，数据库的访问量飞快增长，面临着第二年服务器数量需要翻一倍甚至几倍的局面。业务方忙于寻找解决方案的时候，阳振坤主动找上门去提出了可以用OceanBase帮他们解决问题，把服务器数量降低一个数量级。

四个月出Demo，八个月出试用版，一年后系统正式上线，淘宝收藏夹就这样成了第一个吃OceanBase螃蟹的业务，新数据库取得了非常好的效果。

这时候是2011年，收藏夹项目成为了OceanBase第一个小小的里程碑。

但在后续一年多的时间里，OceanBase团队一直在寻找更多业务，也确实有一些业务用了，却再也没有找到像淘宝收藏夹效果这么显著的业务。

做数据库难度大、周期长，前几年的投入也许有那么一点点产出，但其实跟投入比几乎微不足道，团队面临的压力可想而知。

数据库少不了人力投入，OceanBase团队从最早只有阳振坤一个人，后来发展到2012年已经有30多个人了。

占了这么多人头，但在公司里却没有足够多、足够重要的业务，没能产生足够大的价值和效益。团队陷入了一个比较困难的时期，甚至数度濒临解散。

当被问及“中间有没有想过这事如果没做成，怎么办？”，阳振坤回答得云淡风轻：“ 不是每件事都能做成，那太难了。 如果每件事在做之前都想着它能不能做成，那最后做成的事就会很少。 ”

做数据库就像在黑暗中前行，守得住寂寞、担得了压力，甚至要有近乎偏执的性格才可能跨越死亡之谷，到达最终目的地。

阳振坤团队中一位新人曾经向他表达过自己的困惑，当时这位新人入职三个月了，因为有太多东西要学，什么也没做出来，而跟他同时入职天猫的新员工才来了一个月，做的系统就已经在线上使用了。阳振坤当时给新人讲了一个故事，他说：“你过三年再看，没有人还记得那个同学三年前在天猫上把网页做了什么改版，可是三年以后你今天做的东西还会在生产系统中使用。”

破 茧

在最困难也最危险的时候，团队迎来了一丝转机。2012年底，公司把OceanBase整个团队调到了支付宝。

2013年夏天，支付宝也开始启动“去IOE”，并希望能够把Oracle数据库替换掉。阳振坤又一次主动出击，向当时的主管、也是现在蚂蚁金服的CTO程立自荐了OceanBase的解决方案。

金融行业数据库，最怕的就是突发故障导致数据丢失，涉及到钱的事，多了少了都是不可接受的。为了解决高可用与主备库数据一致的矛盾， OceanBase将可用性做到了数据库系统内部，用一主两备或一主多备代替一主一备。

主库到备库同步的时候不要求同步到每个备库，而是同步到包括主库在内的多数库（超过半数），也就是说总共三个库中如果有两个成功了，这个事务就成功了。如果任何一台机器出了问题，这个系统的可用性和数据一致性都是可以保证的。

程立认可了阳振坤提出的方案，OceanBase团队开始埋头开发，第一个要攻克的目标是支付宝交易库。 2014年双11，OceanBase迎来了第一次大考 。

大促开始前的凌晨，各个团队都在自己的作战室里热火朝天地准备。当时任蚂蚁金服董事长的彭蕾去了OceanBase团队的作战室，问大家：“有没有信心？”

阳振坤跟彭蕾开了个玩笑说： “ 你看我们窗子都已经打开了，如果等会出问题，我们就准备从这跳下去。 ”