OceanBase：蚂蚁爬上舞台
The following article is from 浅黑科技 Author 史中 浅黑科技
2010年过去了，我很怀念它。
这一年发生了很多场著名战斗：乔布斯一边和病魔对抗一边和谷歌缠斗，并且抽空发布了 iPhone4，用人生最后一段光阴拉开了移动互联网的大幕；360和腾讯也打得不可开交，像甄嬛一样争夺桌面时代用户们最后的宠幸；达摩面壁的天河一号超越“美洲豹”，第一次代表中国夺下世界上超算的宝座。
这一年还发生了一场“非著名”战斗：甲骨文 Oracle 在最权威的数据库性能测试“TPC-C”中跑出史诗级高分30249688，一骑绝尘飙到了死对头 IBM 的将近三倍，为数年的缠斗画上钢铁般的句号。
Oracle 提着带血的刀站在斗兽场中心，大喊：“还有谁？？？？”虎啸山林，万马齐喑。
此后各个国家的银行转账、存款保险、航空客票、电子商务的每一笔交易，凡是涉及数字和钱的，都要存在 Oracle 的数据库上才最放心。这个星球上几十亿人的衣食住行，生生把甲骨文创始人拉里·埃里森推上了福布斯富豪榜第五位。
也正是在这一年，两个人在阳振坤的脑海里结结实实打了一架。末了，他还是背起包，温文尔雅地递交了辞呈，从百度大厦搬到了阿里大楼。
阳光刺眼，未来并不是清晰可辨。
（一）“账本危机”
我们的故事不妨先从葫芦娃说起。
打败蛇精之后，爷爷把妖精的金银财宝都抱回村子，带着葫芦娃在村口开了一个小银行——“葫芦娃农村合作信用社”。他们搞了一个小账本，用来记录每天乡亲们存了多少钱，取了多少钱，转了多少钱。由大娃专门负责记账。
爷爷经营有方，银行越做越大，然而问题也随之而来：
每天资金流水数以亿计，需要一个超厚的账本才能把账记全。于是爷爷找到卖账本的老板：“我想定做一个超级厚的账本。”没想到账本老板一摊手：“对不起，工艺限制，我们做不出更厚的账本了。。。”
眼看银行还在不断做大，肿么办？爷爷只好从老板那买了好几个独立账本，把乡亲们的户头分在不同的账本上，让每个葫芦娃分别记账。
这个办法解决了记账的燃眉之急，却带来了一个新问题——每天晚上银行要盘点总账，但由于账本是分割的，没办法汇总。爷爷只好派七娃在每天打烊之后，专门把所有账本的关键数据都抄在一起，做成一个“数据仓库”，在仓库里做最终的汇总、报表。
然而“不解风情”的用户还是继续从四面八方涌来，银行家爷爷为了服务好这些用户，每天都让七娃用各种姿势算数据，七娃不堪重负，仰天长啸：“本来以为蛇精就够狠的，没想到最狠的是爷爷。。。老子要辞职！！！”
这不是童话，是差一点就要发生的现实。故事里的“银行”就是支付宝，“账本”就是数据库，“卖账本的老板”就是数据库公司甲骨文（Oracle），而“葫芦娃”就是支付宝的服务器。
那是2013年，支付宝实名用户数超过3亿，全年支付27.8亿笔，稳坐中国互联网支付平台第一把交椅。舞台上歌舞升平，舞台基座却开始微微颤抖——用来存储用户数据的 Oracle 数据库就像一个气球，此时已经被撑到极限，谁都不知道“砰”的一声何时来临。
“账本危机”像是露出海面的鲨鱼鳍，虽然目前一切仍在掌握，但海面之下却是血盆大口。留给中国队的时间不多了。
2013年夏天，时任支付宝 CTO 鲁肃召集各位技术大佬开会商量这个问题，所有人都表情凝重。说来说去，似乎也只剩一条路——像“爷爷”那样先把数据库拆成几份，解了燃眉之急，后面的事再从长计议。
就在这时，一位老哥悠悠地说：如果各位信任我，用“分布式数据库”代替 Oracle，我向大家保证，我们能把数据库做到无限大！
大家齐刷刷看向他，目光各异。
没错，这位老哥就是三年前加入阿里巴巴的阳振坤，他口中的“分布式数据库”，就是他带着同学们从零开始研发，彼时刚满三周岁的 OceanBase。
（二）“无限大”的梦想
首批长江学者，国家科技进步一等奖得主，王选院士的爱徒，激光照排技术的重要贡献者，中国分布式计算的推动者，分布式金融级数据库 OceanBase 的创始人，要是阳振坤把这些头衔都做成勋章，可以像苏联元帅一样把胸前挂满。
但是勋章冰冷，棱角难近。
所以，在我的故事里，阳振坤没有那些头衔，也不是比我父亲小三岁的大叔，他一直是那个1984年考上北大数学系的19岁少年。
阳振坤
阳振坤第一次接触分布式系统，还是在2006年，那一年他加入微软亚洲研究院。
微软亚洲研究院，是中国计算机科学的黄埔军校。李开复、张宏江、沈向阳、汤晓鸥、王晓峰、余凯这些灿若星辰的大牛，几只手都数不过来。而当时阳振坤汇报的对象，是个比他大三岁，但和他一样倔的老哥，此人名叫王坚。
技术人都有股清高，虽然那一年阳振坤几乎天天和王坚“吵架”，但是他俩在内心里却有了一个大共识——分布式系统才是这个世界的终极未来。
中哥卖了半天关子，到底什么是“分布式系统”？下面就紧急插播一段科普。
分布式系统的原理很简单：把一个大机器干的活分给无数个小机器一起干，从而大大提高系统的整体性能。（这个设想最初是由谷歌在2006年提出来的。）
举个栗子：
1、关二爷斩颜良诛文丑过五关斩六将，但他就是再厉害，世界上也只有一个关二爷。一人独自面对百万大军腿也软。关二爷就叫“单机”。
2、关二爷一个人不行，把刘备关羽张飞捆在一起呢？虽然是兄弟三人并肩作战，但他们三个还是独特的，不能无限复制。刘关张就叫“集群”。
3、诸葛亮运筹帷幄，指挥蜀军帐下千军万马，东挡西杀，部分将士有死有伤，也并不影响整个军队完成战争使命。一场战役下来还可以继续招兵买马，扩充实力。蜀军就叫“分布式系统”。
你可能会说，中哥怎么还整出来《三国》了，分布式系统听上去跟我没啥关系啊。。。
你错了，摸摸口袋，只要里面装着智能手机，这事儿就铁定和你有关——你去饿了么点外卖，去淘宝剁手，在微信聊天，十几亿人每天无数次次数据交互、调度、运算都是由“云计算”完成的。而“云计算”其实是个小名，它的大名恰恰就叫“分布式计算系统”。
一句话：没有分布式系统，就没有我们今天的世界。
相比“单机系统”和“集群”，“分布式系统”有两个明显的好处：
1、扛造。
打个比方：蚂蚁社会就是个分布式系统——这个家族的生存任务被分摊在每一个蚂蚁头上；出门执行任务的个体蚂蚁难免遭遇鞋底、车轮等等不测，但这并不会影响整个蚁穴的运转；而且就算蚁后被捉走，蚂蚁们也能临危不乱迅速选出新蚁后，继续产卵生子母仪天下。
2、无限大。
道理是很简单的数学：1+1=2，1+1+1+1+1......无数个1加起来就是无限大。只要在技术上实现对每一台机器的“自动调度”，分布式系统就是没有上限的。
别忘了，命运赠送的礼包越大，暗中标定的价格就越贵。老司机攻克“分布式系统”的技术，难度不亚于夺下恶龙守护的珍宝。
江山多娇，无数英雄竞折腰。
说回我们的故事。阳振坤和王坚都有济世情怀，不愿意“躲在小楼成一统”，而是梦想着让自己手中的技术能给世界带来肉眼可见的改变。
于是，2007年阳振坤去了百度，2008年王坚去了阿里巴巴。他俩做了同一件事儿——云计算。
历史的裂痕就此绵延。当时的“互联网一哥”李彦宏羽扇纶巾，全情投入梦想中的人工智能，却把云计算称为“新瓶装旧酒”；而千里之外的杭州，不懂技术的马云却被王坚“忽悠”，拿出了十个亿支持他做“阿里云”。
王坚
时间终于走到了2010年，文章开头的那一幕出现——阳振坤“未敢翻身已碰头”，在阿里巴巴合伙人刘振飞的邀请下，终于下定决心出走百度，转投阿里巴巴。
来到阿里巴巴，继续做熟悉的云计算应该是顺理成章的事儿。不料，阳振坤的老司机本色开始显露。。。
离开前一家，之前的项目我就不会再做，因为之前的技术、关系网很多，容易引起纠纷，让别人说闲话。我离开方正后，就不做激光照排，离开百度后，就不做云计算。
阳振坤解释。
这种“避长扬短”的孤傲着实令很多人费解，但他就是这样做的。
那么问题来了， 除了云计算，哪个技术最有前途嘞？挑来挑去，他选中了“分布式数据库”。
为啥是数据库？
这和王坚当时在阿里巴巴力主推行的“去 IOE 行动”有关。
2009，是“双11”元年，阿里巴巴如火山待燃。为了给剁手党们提供顶级的服务，无论是淘宝还是支付宝，都大批购买昂贵的 Oracle 数据库，把用户的核心数据跑在上面。
但是，盛世和危机只有一线之隔。
你还记得第一章我们讲的支付宝“账本危机”吗？淘宝同样遇到这个问题，而且要比支付宝更早：
2010年时，一个 Oracle 数据库已经没办法支撑淘宝巨大的交易数据，危机迫近，淘宝只好像“爷爷”一样，把数据库拆成相互独立的子数据库，然后用“数据仓库”的方式每日汇总。
然而问题来了，假如把1个大数据库拆成100个子数据库，100个子数据库就要买100个 Oracle 软件授权，为了运行这些数据库还同时要配备100台（或更多）IBM 小型机，还有相应的 EMC 高端存储（这三个并称IOE）。
这可不是开玩笑的，把阿里巴巴所有的利润拿来买这些“奢侈品”都不够。。。
王坚手捧预算，铁血站在此地，从此时此刻起不准购买一套新的 Oracle，退半步者，斩立决。
于是，当时淘宝把数据库拆分后，很多子数据库都换成了开源的 MySQL 数据库，只有少部分最核心的数据仍然跑在既有的 Oracle 上。（你可以简单把 Oracle 理解为 iOS，把 MySQL 理解为安卓。MySQL 开源免费，比 Oracle 实惠得多，但二者都是同一代技术——集中式数据库。）
然而从阳振坤这个“技术完美主义者”的角度来看，用 MySQL 代替 Oracle 并不解决根本问题，因为这种“拆账本”的方式本身就是下策。他甚至想：如果自己能早点来，早几年开发“分布式数据库”，直接用分布式数据库代替 Oracle，不仅能去IOE，还能避免“拆账本”的情况发生，一举两得。
但历史没有假设，种一棵树最好的时机是十年前，第二好的时机就是现在。
阳振坤这位老司机，就这样分秒必争地开车冲上“分布式数据库”这条赛道。
只是彼时的他，尚未预料到数据库这条路比秋名山还凶险。。。
分布式数据库技术具体有多难呢？
简单说，要想账头一分钱都不错，数据库要符合一个叫做“ACID”的原则，这四个字母分别代表：A原子性，C一致性，I隔离性，D持久性。
原子性：A转给B100块钱，A账户扣除100块的同时，B账户必须增加100块钱。这两件事必须像一个原子一样紧紧抱在一起，决不允许“A已经扣钱，B还没加钱”的事情发生。
一致性：A转给B100块钱，转账完成的一瞬间，A瞬间再查询自己的最新余额，必须显示已经扣除100之后的金额，B必须瞬间查到已经加上100块之后的余额。所有的账目在任何一个时间切面必须完完全全对得上。
隔离性：A转给B100块钱，不能对C有任何影响。
持久性：A转给B100块钱，这笔转账一旦完成，就永远生效。
问题来了：
如果是集中式账本，只有一个葫芦娃负责写入，保证 ACID 就容易得多；
但是分布式数据库是让无数个葫芦娃千手万脚地在一个超大型账本上记账，相当于指挥整个幼儿园的熊孩子整齐划一地左手画龙右手彩虹胸口比划郭富城，此时要保证 ACID，就比登天还难。
一句话：2010年的世界上，能保证 ACID 的“分布式数据库”根本就不存在。
当时淘宝的核心技术由吴泳铭负责，他是阿里巴巴第一位程序员，早在阿里建立之前就跟随马云东挡西杀，人称“吴妈”。（其实是男的。。。）
吴妈伸出两个指头：“阳老师，我可以给你两年的时间来证明“分布式数据库”是可行的。”
阳振坤呵呵一笑：“用不了。”
“后来的事实教育了我，分布式数据库是所有分布式系统里最难的那个。。。”
坐在我对面的阳振坤苦笑。
阳振坤，拍摄于2010年。
（三）“收藏夹”第一战
2010年6月，光杆司令阳振坤出街。
他眼前要处理的问题有千千万，但最主要的就一个：没人想用，也没人敢用他的“分布式数据库”。
由于当时淘宝的数据库已经拆分。拆都拆了，换上的 MySQL 又基本运行平稳，脑子正常的人谁也不会再折腾这件事儿了。
于是45岁的阳振坤拿着自己的 PPT 在淘宝各个业务线奔走宣传，像极了一个亟需养家糊口的“大龄推销员”。要是那时候有微信，他肯定每天两万步。
功夫不负苦心人，总算有一个团队愿意吃螃蟹，那就是淘宝里的一个小版块——收藏夹。
收藏夹团队之所以要吃螃蟹，也不是因为他们看好分布式数据库，而是有一个实实在在的“难言之隐”。
什么难言之隐呢？
来，回忆一下你使用收藏夹的过程。
假如你收藏了100件商品。点开收藏夹，100件商品就会瞬间跳到你的眼前，每一个商品都显示它的实时状态——比如最新价格是多少，是否下架，等等。
你可能想不到，就是这么轻轻一点，却苦了收藏夹背后的数据库，那一刻它要去淘宝商品库里挨个调取每一件商品的实时详情，相当于一瞬间把100件商品访问了一个遍，再把所有需要更新的价格、状态一一写进自己的数据库，最后呈现给你。（这一切都在零点几秒内发生）
这里要科普一个小知识：商品的价格信息往往就是一两位数，换成计算机术语就是1-2个Byte，但由于技术限制，计算机对硬盘操作最小的单位是4KB，4KB=4096Byte。也就是说，如果数据库只想改一个价格信息，它也必须读出来一整块4KB的数据，然后只修改其中几个数字，再把4KB数据整体写回数据库。
蓝色是读出的整数据块，红色为其中修改的部分。注：由于数据读出来之后，原存储位置被释放，所以一般会写回到另一个地方。
所以，如果一次性读取100个商品，虽然只有其中一小部分商品的参数发生变化，却会对数据库额外进行几千倍的写入，让数据库服务器忙得不可开交——这就叫做“写入放大”。
当时收藏夹的服务器只有100台，眼看人们在收藏夹里堆的商品越来越多，团队壮着胆子为明年申报了400台机器的预算，就这样还不一定够。。。
阳振坤听完了收藏夹团队的难言之隐，眉头一皱，计上心来。他的办法如下：
“内存”这种东东没有4KB的调取下限，而且读取速度是硬盘的100倍左右，所以只要新设计一个数据库，把商品的最新信息放在内存里。用户访问收藏夹的时候，数据库先去硬盘上把基础的数据找来，再去内存里读取最新改动的部分，叠加之后呈现给用户，问题就解决啦。
每过24小时，通常在后半夜比较闲的时候，数据库会统一把前一天内存里的“增量数据”写入硬盘，清空内存，来日再战。（这种闲时集中写入还有个好处：可以把数据压缩比做到极致，节省60%左右的存储空间。）
你可能会问，这样的话还要在内存里标注每段数据对应着数据库上的哪个位置，这不也是额外信息吗？你说得没错，在每个数据旁边，都要加一个指针，标明它是用于更新数据库里哪个参数的。但是即便加上这些信息，写入放大也只有大概几十倍，比硬盘的写入放大低两个数量级。（以当时收藏夹的状况，10G内存就够了。）
这样算下来，收藏夹团队用现有的机器就能轻松应对再多100倍的数据量。
听上去很不错吧。收藏夹的同学也觉得不错，给了阳振坤老湿一个月的时间把吹出去的牛逼实现，结果阳振坤弄了八个月才交货。。。。
为啥这么久？
各位别忘了，解决“写入放大”只是阳振坤的支线任务。他的主线任务是把这个数据库做成“分布式数据库”。
当时阳振坤刚刚招了几个应届生同学——解决写入放大，一个月真差不多；把分布式数据库的底座写出来，一年算是快的。
虽然时间紧急，团队还是决定给这个“分布式数据库”起个名字先。一位同学提议，既然我们的目标是星辰大海，要让无远弗届的巨大数据库降生在这个世界上，不如就叫“海洋”，翻译成英语很好听，叫 OceanBase。
矮油不错哦，大家把这个主意告诉阳振坤，求夸奖。
阳振坤当时正急得焦头烂额，说：“叫啥都行，咱们赶紧研究技术吧！”
OceanBase 的名字就这么稀里糊涂地定了。。。
具体来说，OceanBase 想要做成“分布式”，得解决两个难题：“分布式读”和“分布式写”。
先说简单一点的“分布式读”。
收藏夹数据库连着50台终端机，终端机的角色就像银行柜员一样，在普通用户点开收藏夹的时候，它们负责对100台服务器组成的分布式数据库进行读操作，然后把数据返回给用户。
由于数据散落在100台服务器上，所以50台终端机中的任何一台都有可能连接100台服务器中的任何一台，也就是50*100=5000条可能连接。但这个数目太大了，无法稳定维持，所以需要定期断掉其中不常用的九成，同一时刻只留500条左右的连接。
如此，问题基本解决。
再说难一点的“分布式写”。
对于这个问题，阳振坤的解决方案是——暂时不解决。
是的，你没看错。当时时间已经过去半年多了，而试验了几个技术方案，都没有很好地解决“分布式写”的问题，OceanBase 拖着交不了货，收藏夹团队气得要死。讲真，收藏夹团队关心的“写入放大”问题已经解决了，“分布式的写”能不能搞定，那是你阳振坤自己的追求。
眼看2011年的“双11”就要来了，一大波剁手党即将抵达战场。目测如果 OceanBase 再不交货，收藏夹铁定要跪，他们已经开始磨刀准备来砍人了。。。
没办法，OceanBase 只好暂时放弃技术攻关，把写入增量数据的内存都集中在其中一台机器上（集中式写入），就这样交付了。
有意思的是，OceanBase 团队保持着一贯“不输嘴”的高傲，把这个版本命名为 OceanBase 0.1 版，意思就是：这个东西在我心里只完成了一点点，哼！
0.1 就 0.1 吧，对于收藏夹团队来说足够解决燃眉之急。虽然还有不少小 Bug，但幸好都在“双11”之前排查清楚，收藏夹擦着冷汗，安全冲过那年“双11”。
OceanBase 首战告捷。
嗯。。。基本告捷吧。
（四）“两年倒计时”和出走支付宝
阳振坤站在广场上吆喝：“收藏夹第一个吃了螃蟹，谁愿意做第二个？”
大家都往后退了一步。。。
2012一整年，阳振坤疯了一样把团队十几个同学都派出去，逮住人就问：你要不要用 OceanBase？
然而，只有零星几个小业务“礼貌性”地用了 OceanBase，不值一提。大家暗地里口耳相传：听说了么，OceanBase 能把一个月的活儿干成八个月，双11前还在修 Bug，差点把收藏夹给坑了。。。
不过阳振坤却不完全认同：
数据库就和年轻人一样，是磨练出来的，越用才能越发现问题所在。你看 Oracle，那是磨练了四十年的结果，如果一个大学生刚刚参加工作，老板总不给他机会，那他怎么成长呢？
道理大家都懂，可是真求到哪个业务，业务同事们又都咂咂嘴，语重心长：阳老师我不是不帮你，我这不太合适啊。。。
就这样，时间推进到了2012年秋天，吴妈的“两年之约”眼看就到了。结论很明显，“分布式数据库”没能证明自己，阳振坤站在信任的荒原上，心急如焚。
10月底，阳振坤再也忍不住了，一拍桌子，从北京飞到杭州，坐在了阿里巴巴 CTO 兼老同事王坚的办公室里。
王坚能帮他么？不好说。
说实话，那段时间王坚自己的日子也并不好过。他力主创造的阿里云，同样是从零开始研发，彼时正经历大家最激烈的的嘲讽和白眼。大批优秀的程序员实在看不到光明，在这年秋天深鞠一躬，就此别过。阿里云摇摇欲坠。
两人相对无语。做成一件事有多难，彼此心里谁不清楚呢？末了，王坚对阳振坤说：“你放心，先回去吧。我心里有数了。”
两周之后，一纸调令在集团公布：
2012年11月15日，OceanBase 所有人员从淘宝调入支付宝。
把 OceanBase 团队调入支付宝，王坚是有战略考虑的。
1、淘宝已经把“账本”拆分，而且用了开源的 MySQL 代替了 Oracle，不适合冒险使用理念这么超前的数据库。
2、支付宝尚未把“账本”拆分。究其原因恰恰是它直接和钱打交道，对于数据的安全要求极高，如果用 MySQL 代替 Oracle，以当时的技术发展水平有一定的风险，不敢轻举妄动。
3、如果在支付宝，OceanBase 有能力获得信任，有朝一日直接替代 Oracle，支付宝的数据库技术就不仅去了 IOE，还不用拆账本，还实现了技术跃迁，一箭三雕。
当然这一切只是王坚的设想，他也只能帮到这了。余下的，就看老伙计阳振坤有多少真本事了。
果然，加入支付宝几个月后，第一章提到的“账本危机”就不得不提上日程了。
“如果各位信任我，用“分布式数据库”代替 Oracle，我向大家保证，将来我们能把数据库做到无限大！”
此刻你再体会阳振坤在会上说的这句话，就已经不是一个技术大佬的低调炫耀，反而颇有背水一战的味道了。
听完阳振坤的毛遂自荐，鲁肃沉默很久，提出一个直击灵魂的问题：
你 OceanBase 用什么技术来保障账户不丢一分钱？
阳振坤敢揽瓷器活，一定是怀里有金刚钻。过去一年，虽然没有大的业务“临幸”，但是 OceanBase 的技术一直在同事们的努力下稳步迭代。
OceanBase 解决这个问题的方法就是“三副本”。
“三副本”是个啥？
1、三套 OceanBase 数据库绑在一起工作，一个做“主咖”，两个做“备胎”。假如你在支付宝上发起一笔转账，这个信息会同时发给三个库。
2、主咖接到转账申请后，先不着急记录在案，而是询问两个“备胎”，你们是不是也收到了这笔申请。
3、至少一个备胎回复“收到”以后，主咖才会把这笔交易记录在案。于是，每一笔交易都会保证至少由两个数据库记下来，所以任何一笔交易都不会丢失。
这种操作不是阳振坤的原创，而是源自1989年的一篇论文，最早的实际应用大概是在2000年左右的谷歌内部。只是在2013年的中国，还没有人这样摆弄数据库。
平心而论，鲁肃是不世出的技术天才，一个技术能不能管用，有没有漏洞瑕疵，他用鼻子都能闻个八九不离十。听完这个技术构想，他说：“阳老师，我支持你去试试。”
鲁肃的话说得很谨慎，这也是不得已。
如果 OceanBase 的步子迈得太慢，那么支付宝面对迫近的“账本危机”就可能少一样重武器，吉凶未卜；如果 OceanBase 的步子迈得太快，万一技术真有缺陷，但凡丢了用户一分钱，对支付宝的声誉都是毁灭性的打击。别说鲁肃，谁都负不起这个责任。
不过，至少得到了口头支持，阳振坤开心地回到团队，带领大家开始了 OceanBase 的“三副本”升级。
又是一年寒暑。
（五）从1%到10%，从0.1到1
到了2014年5月，OceanBase 三副本终于就绪，版本号升级为 0.5。
可是那个梦魇一样的老问题又出现了——没有业务团队敢吃螃蟹。。。至于为什么不敢用 OceanBase，又都说不上来。他们只是支支吾吾：感觉不稳定，害怕性能差，担心出问题。
就这么干挺了两个月，每一天对于阳振坤来说都是漫长的煎熬。他终于忍不住了，给鲁肃、井贤栋和蚂蚁金服 CEO 彭蕾发了一封邮件。
团队的同学们看我的眼神，每天都从希望到失望，我是真的不知道怎么给他们交代。情急之下，才冒昧写了这封信。
阳振坤回忆。
那封信发出一星期后，鲁肃找到阳振坤：“在接下来的双11，OceanBase 会承担支付宝交易流水库 1% 的流量，我叫了交易流水团队的同学，咱们一起对接！”
鲁肃亲自坐在督战室，对业务团队的同学说：你说说看，OceanBase 到底有什么问题，要说具体的，不能说“感觉不稳定，害怕出问题”这些虚的。
我特别感谢鲁肃，虽然只是给了流水库的1%，但是他当时肯定承受了巨大的风险和压力，这是对我莫大的信任。
阳振坤对我说。
流水库的 1% 由 OceanBase 承担，那剩下的 99% 呢？当然是老牌选手 Oracle。
然而戏剧性的一幕出现了。
就在双11来临之前，阿里巴巴会进行“全链路压力测试”——模拟双11当天的流量洪峰，检查技术上有没有疏漏。
结果，承担99%流量的 Oracle 屡次崩溃，无论如何通不过测试，而一旦把它承担的流量降为90%，就恢复正常。。。事实已经很明显：Oracle 的实际性能极限已经被触碰到了。
于是就在双11来临前两周，鲁肃临时修改计划，让 OceanBase 承担10%的流量，阳振坤团队临危受命。
11月10日晚，蚂蚁金服 CEO 彭蕾专门来到 OceanBase 的作战室，问阳振坤：“阳老师有信心吗？”
阳振坤指指窗户，窗外深秋的树叶正在风中婆娑。“不成功我们就跳下去。”他平静地说。
“当时你们在几楼？”我问。
“7楼。”他说。
“如果没成功，你真的会跳吗？”我问。
“我们的 OceanBase 实际上部署了承担100%交易数据库的能力，也就是说如果 Oracle 完全不起作用，我们也能扛起来，这个技术自信我是有的。”阳振坤笑。
现在阳振坤活生生地坐在我面前，你应该能猜到，那次“双11”的结果可以用完美来形容。
OceanBase 一战成名。
2014年底，阿里巴巴集团召开了“双11”复盘会。阳振坤作为演讲者，从头到尾分享了 OceanBase 的技术构想和艰辛历程。
这一场分享，深深烙在阳振坤的记忆里，挥散不去。
正是从那时起，OceanBase 这个曾经被“嫌弃“的少年，一点一点努力奔跑，摆脱了死神的追击，被越来越多同事和技术人发自内心地接受和尊敬。
OceanBase 后来获得了2015年蚂蚁金服最重磅的奖项——SUPER MA。这是时任蚂蚁金服 CEO 彭蕾在给 OceanBase 团队颁奖。
OceanBase 果然人如其名，真的和海洋一样，差点把创始人都”淹死“。。。阳振坤在水面之下潜行五年，此刻也终于可以浮出海面，舒爽地换一口气。
不过也仅仅是换一口气——此时摆在他面前的，还有那个早就应该解决的大难题。
你还记得吗，OceanBase 还是个半成品，它只解决了“分布式读”的问题，没能解决“分布式写”的问题。
其实，经历了两年多时间，这个问题的解决方案在阳振坤的脑海里已经成熟，只是团队生死未卜，一直没能腾出手来做升级。
接下来中哥就给你科普一下“分布式写”是怎么解决的。
分布式写最大的难度其实就在于保证 ACID 中的那个 A——原子性。
还是举那个例子。
假设 A 给 B 转100块钱，由于是“分布式数据库”，A用户的账户存在A机器上，B用户的账户存在B机器上。
如果交易发生时，负责给A账户扣100块钱的A机器死机,没有扣成功，而负责给账户B加100块钱的B机器工作正常，加上了100——这就会造成支付宝损失100块。
反之，如果负责给A账户扣100块钱的A机器正常，已经扣掉100，而负责给账户B加100块钱的B机器死机，100块没加上，那么用户就会损失100——最后支付宝还要赔偿用户100块。
为了保证以上这两种尴尬的局面不发生，OceanBase 1.0 采用了整整一组技术，但最主要的是两个，我给你讲讲。
1、投票机制。
刚才说过，数据库是“三副本”，也就是任何一个账户，都有一个主咖两个备胎共三份相同的数据。
举例来说：账户A的数据一定同时存在三台机器上。转账时，至少两台机器执行完毕才算转账完成，
这意味着，三台机器里有一台坏掉，并不影响转账的执行。
同时，三台机器之间相互实时发送“心跳信号”，如果有一台机器挂了，其他两台马上就能感觉到，处理完手头这个交易后，马上向系统发送警报，系统自动为他俩匹配一个新搭档，三台机器继续工作。
而换下来那个坏机器，交给技术人员维修，修好后重新上架成为备用机器，等待进入战斗序列。
也就是说，除非两台机器在同年同月同日同分同秒同毫秒坏掉，否则数据库的工作不受影响。
即使是这还不够，在关键的节点，OceanBase 会采用五个节点投票。也就是除非三台机器在同年同月同日同分同秒同毫秒坏掉，否则数据库的工作不受影响。这个概率已经低到尘土里了。
2、监督机制。
仔细想想，除了机器坏掉，还有一些情况会破坏交易的原子性。
例如：A账户要扣掉100块，但是它的余额只有90块，或者已经达到了今天的转账限额，这种情况下，如果贸然给B账户加了100块，A账户却不够扣，就会陷入麻烦了。。。
反之如果B账户状态有异常，不能加100块，同样会有麻烦。
解决这个问题的方法，就是引入一位“裁判员”。
裁判员站在A账户和B账户旁边，它的工作流程是酱的：
1）裁判员问A账户：你的三台机器都没问题吧？A账户说：没问题。
2）裁判员问A账户：你的账户允许扣100吗？A账户说：允许。
3）裁判员问B账户：你的三台机器都没问题吧？B账户说：没问题。
4）裁判员问B账户：你的账户状态能接受加100吗？B说：允许。
5）这时，裁判员吹哨，A、B账户同时冻结。
6）A扣100，B加100，双方向裁判汇报“成功”。
7）裁判员再吹哨，A、B账户同时解冻。
以上7步，都是按时间顺序完成的，卡在任何一步，账目都不会乱，一分钱都不会丢。完全符合“原子化”的要求。
监督机制示意图，当然裁判员也由三台机器组成。
直到解决了“分布式写”，分布式数据库的所有技术障碍才被打通，用于存储新写入内容的内存可以分布在每一台服务器中，就像下面图示：
就这样，2016年，一个真正的分布式数据库 OceanBase 1.0 横空出世。阳振坤跑了六年的梦想马拉松，终于看到了第一个里程碑。
而自天空俯瞰，一场“角马大迁徙”正在发生。
自从2014年支付宝交易流水库采用了 OceanBase，蚂蚁金服的其他业务开始一个个告别 Oracle，越过湍急的河水，冲向了分布式数据库 OceanBase 的彼岸。
这场迁徙越来越壮阔，在赛博空间里扬起尘土，在技术人心中暴裂无声。
到2017年底，蚂蚁金服核心系统中的最后一个 Oracle 数据库被 OceanBase 替代。从此，Oracle 只出现在蚂蚁金服的历史博物馆中。
正如阳振坤所预料的那样，几亿用户对于 OceanBase 的淘洗磨练，不仅没有击垮 OceanBase，反而让它的表现越来越稳定。OceanBase 处理的所有账目，一分钱都不会错。
不过，在阳振坤眼里，Oracle 绝不是被他们秒掉的渣渣，恰恰相反，Oracle 一直是他们心中的榜样——OceanBase 七年征程，只是接近了老大哥的背影而已，并无值得骄傲之处。
况且在2017年，OceanBase 和 Oracle 比较，还有一个硬伤。
是什么硬伤呢？
你还记得“葫芦娃农村信用社”的故事里，爷爷为了服务好乡亲们，需要每天晚上让数据库用各种姿势分析报表么？
2017年的 OceanBase 分析报表的能力其实是很弱的。
究其原因，还是“分布式”造成的——在“分布式数据库”的技术体系里，A给B转账，C给D转账，这两笔转账互不干扰，如果你非要问它俩哪个在前哪个在后，OceanBase 就无法精确统计了。用专业术语讲就是：做不到事务的“串行化”。不知道先后，很多分析就做不了。
而老大哥 Oracle 由于是集中式数据库，相当于所有交易都是一个葫芦娃完成的，那显然每一笔交易的先后顺序都能排得清清楚楚，什么姿势的报表都能出，杠杠的。
为了解决“串行化”问题，他们必须马不停蹄继续奔向 OceanBase 2.0。
终于，在2018年，OceanBase 团队搞定了串行化的技术，他们解决的方式是酱的：
在数据库身旁，专门设立一个节点，这个节点什么都不干，只负责一件事——发号。
你去饭店吃饭的时候，如果人太多，服务员会给你一个号对吧。这也是类似的原理：
1）数据库里的裁判甲要进行操作时，要先跟“发号员”申请一个号段，例如10000-20000号。
2）裁判甲把自己要做的操作在自己内部排好顺序，例如10001、10002、10003。。。。。
3）这样在整体数据库里，每一个操作就有了自己独特的编号，且不会重复。例如“A转100给B”这个操作是10005号，“C转100给D”这个操作是20456号。那么，“C转100给D”就一定发生在“A转100给B”之后。
搞定串行化之后，OceanBase 已经在功能上追到了 Oracle 的 40%左右。没错，用了八年只追上了 Oracle 的 40%，这就是中国公司和美国公司的真实差距。
但我们也不用妄自菲薄，由于采用了下一代的分布式架构，OceanBase 实现了“无限大”的扩展性，在性能方面比 Oracle 高到不知道哪里去了。
虽然“士兵甲”“士兵乙”单打独斗打不过关二爷，但是千军万马生擒关二爷却是情理之中的。这像极了《三体》中所描述的“降维打击”——高维空间的蚂蚁，可以穿透低维空间的大象。
OceanBase 2.0 全局示意图
（六）登顶“珠峰”
虽然在蚂蚁金服内部，OceanBase 已经接过 Oracle 的接力棒，但放眼望去，中国的无数银行、金融机构却没有如此强的研发力量——他们仍然被困在低维空间，使用 Oracle 或类似的国外数据库。
穷则独善其身，达则兼济天下。阳振坤决定兼济天下。
2015年，阿里巴巴主导的银行网商银行使用了 OceanBase 数据库。2017年，南京银行的互联网银行业务使用了 OceanBase 数据库。人保健康险、西安银行、广东农信等陆续有几十家金融机构成为了 OceanBase 的用户。
但是讲真，这个数量比阳振坤预想中要更少。
因为他仍然面临那个古老的命题：
想当年，可是鲁肃、彭蕾、刘振飞、王坚、马云一众大佬的信任，才让 OceanBase 一步一个坎儿在蚂蚁金服生根发芽，如今，各大银行跟你蚂蚁金服又不太熟，凭什么放心地把最核心的业务跑在你开发的数据库上？
阳振坤专门跑去问过很多银行的技术领导：“你们不放心国产的 OceanBase，又为什么放心美国的 Oracle 呢？”
银行的同事说：“你去查查跑分啊，Oracle 是第一名，你 OceanBase 第几名啊？都没有在榜单上。。。”
银行说的“跑分”，正是 TPC-C。
故事讲到这，TPC-C 终于又出现了。到底啥是 TPC-C 呢？
要明白 TPC-C，得先明白 TPC。
1967年，英国印刷公司职员约翰·巴伦突发奇想，发明了一种随时随地都能取到钱的自助提款机，也就是ATM机，80年代，ATM机开始风靡，由于无人值守，它的账目就得通过自动化的数据库来管理，于是各大软件公司纷纷开始研发商业数据库系统，准备趁着风口赚一票。
这时一个问题出现了， 王婆卖瓜自卖自夸。大家都说自己的数据库好，究竟怎么才是好呢？
于是工程师欧姆里·塞林（Omri Serlin）说服了八家数据库厂商，大家统一商量一个标准，就按照这个标准，用跑分的方式测试数据库的能力，谁的分高谁就厉害，童叟无欺。
Omri Serlin
于是，一个专门负责帮大家跑分的组织就成立了，这就是 国际事务处理性能委员会 TPC（Transaction Processing Performance Council）。
TPC 会对数据库很多方面的性能进行测试，而 TPC-C 是其中最主要的——针对在线交易数据库的性能测试。
TPC-C 会模拟一系列的交易动作，例如下单、支付、订单查询、库存查询。谁能处理得最多，最稳定，谁的分就高。
分布式数据库一定可以超越集中式数据库十倍，甚至百倍，这是数学原理决定的。这也是我做 OceanBase 第一天就抱定的信念，不能超十倍百倍，我们为什么要做？
最开始的时候初生牛犊不怕虎，我以为5年就能把 OceanBase 做个大概的。那时候知道数据库这条路有这么难，也许都不会开始了。其实直到今天，我们仍然把 Oracle 作为学习和追赶的对象。他们有太多积淀和闪光点。