阳振坤：数据库天然选择了计算机，但计算机天然并不适合数据库

小蚂蚁说：

2018 年 6 月 25 日，清华大学计算机科学与技术系 60 周年系庆系列讲座第 11 场报告在清华大学东主楼举行。蚂蚁金服高级研究员、OceanBase 负责人阳振坤在本次学术报告中发表了题为《OceanBase 每秒处理 25.6 万笔支付的技术关键》的主题演讲。

阳振坤以行业趋势为切入点，对蚂蚁金服自研的金融级关系型数据库 OceanBase 的发展历程和技术突破点进行了深度剖析。

在互联网世界里，存在着一种怪圈：本地企业为了向本地人群推销本地产品，却每天都在源源不断地把广告费输送给境外公司。在美国，有这么几家巨无霸公司，诸如 Google、Amazon、Facebook 等，已经逐渐垄断了欧洲和日本的互联网应用相关市场。

而反观中国，我们有自己的电商网站（淘宝天猫等），自己的搜索引擎和社交应用（微信，微博等）。我们是否可以自信的说，我们真的达到了国际一流的技术水平？

从互联网应用的角度来看，中国制造的应用在形态上不断演变，不断丰富，我们承认自己确实已经做得比较优秀。但是，在核心基础部件上，我们还有很长的路要走。

今天，从大范围普遍使用的角度来看，中国还不能说真正有自己的处理器，不能说真正有自己的操作系统，也不能说真正有自己的关系数据库。或许有人会说，今天的开源生态日益繁荣，我们完全可以用开源的操作系统，开源的数据库。

OceanBase 负责人阳振坤

给大家提供这样一份数据：在手机市场上，中国每一部安卓手机不仅要给国外某操作系统软件公司缴纳几美元到十几美元的专利费，还要给国外某通信巨头缴纳手机价格百分之几的通讯及芯片的专利费。

而在金融行业，几乎所有银行的关键软件硬件基础设施都来自美国，服务器是 IBM 的，共享存储是 EMC 的，数据库软件大部分是 Oracle，剩下的少部分是 IBM 的 DB2。我们假设，如果某一天真的发生军事冲突，银行系统三年得不到技术支持和设备配件，我们的金融业会怎样？

努力了这么多年，在关键基础的软件硬件设施方面，我们还是把自己的命脉和财富都交给了别人。

为什么要做中国自己的关系数据库？这既是互联网推动的客观需求，也是金融行业数字化转型的必然结果。

互联网时代的全新挑战

在没有互联网的时代，不论是商场还是银行，关系数据库系统的并发量非常有限，从几十、几百相当普遍，几千、几万以上就比较少见了。进入互联网时代以后，并发访问量发生了数量级的增长。2010 年的双十一，高峰期间阿里巴巴的天猫的并发访问量已经达到几十万，再到去年 2017 年的双十一，这个并发访问量已经达到一千多万。这已经是一个从量变到质变的过程。

可以说天猫双十一所带来的现象级的并发访问量是源，推动了整个团队来做这件事。

那么另外一个重要的因素，就是在传统模式下，不管是商场还是银行，它的访问量很稳定，商场/银行扩建时有充分的时间把整个 IT 数据库系统扩展开来。而现如今，我们的网站可能上个星期访问量还是十万级别的，几天时间就可能上涨了近十倍，传统关系数据库系统硬件的半年左右的购买实施周期无法适应业务的变化。

这就是互联网时代数据库所呈现的两种特性，第一是并发量非常大，随之所带来的也是几百上千倍的成本。第二就是负载变化剧烈，带来伸缩性的变化。

大家都知道，2017 年天猫双 11 创造了新的支付记录：25.6 万笔/秒，那么这究竟是个怎样的概念？

简单解释来看，就是为了要达到 25.6 万笔的支付，数据库需要执行 4200 多万条 SQL。用一个更直观的例子，中国的五大行是中农工建交，他们每秒钟的支付能力可能就是一万多笔的体量甚至还不到。

这也就是说，如果支付宝采用同样的解决方案，则需要付出大银行十几倍几十倍的 IT 系统成本。

前言回归关系数据库的本质：事务

数据库之所以有价值，是因为事务。它之所以困难，也是因为事务。用华东师范大学的副校长周傲英教授的一句话来概括，数据库的本质就是做三件事：转账、记账、订票。

生活在今天的现实世界中，没有任何地方能离得开关系数据库。打电话的时候，关系数据库在帮你计费；买火车票，买飞机票，银行存取款，还有各种各样的网站交易等等，在这背后其实都是关系数据库在支撑。所以，毫不夸张的说，关系数据库是今天整个信息社会中最关键，最无可替代的基础设施。

但是，数据库却是个不好搞的东西。如果说数据库中最关键的是事务，其最重要的就是事务的 ACID 特性。

• 原子性（A）：一个事务要么全部执行，要么不执行。比如你从取款机取钱，这个事务可以分成两个步骤：改账户余额，出钱。不能余额减了，而钱没出来。这两步必须同时完成，要么就不完成。

• 一致性（C）：在金融系统中，一个典型的场景就是信用卡主副卡。比方说，你和你的家人使用了主副卡，你花了一笔钱，你们的信用额度都会相应减少，如果你的家人还了一笔款，你们的信用额度都会相应增加。如果是在一台机器上实现起来还没那么难，那么如果在两台不同的机器上，这件事情就会变得非常困难。

• 隔离性（I）：事务在运行的过程中，表现地像是系统中当前唯一运行的事务，不会因为系统中并发执行的另一个事务而访问到不一致的数据。

• 持久性（D）：今天唯一能够有持久性的东西，其实就是硬盘。数据中心硬盘的年故障率约为 2%-4%，所以说如果你的硬盘都坏了，你的数据还会存在吗？

用一句话来总结来说就是：

数据库天然选择了计算机，但计算机天然并不适合数据库。

数据一条不能错，服务一秒不能停

关系数据库在业务系统中处在一个最底层的位置。关系数据库之所以困难，也是因为一个非常简单的道理：数据不能错，服务不能停。

在任何业务系统中，数据库的数据错误都是巨大的灾难，对于金融业务，如果你的系统停止服务超过 30 分钟，你恐怕需要去银监会说明情况。

因为有这两个因素，更换数据库的风险非常高，但通常却没有与之匹配的收益。这也是为什么像 IBM、微软这样的后来者也无法取代 Oracle。这就导致了数据库变成了一个门槛极高，强者恒强的领域，后来者很难居上。

OceanBase：关系数据库的重塑者

传统数据库的局限

上图是一个非常简单的传统数据库的架构示意图。今天 IOE 的体系在银行业已经根深蒂固。虽然 IBM 的服务器和 EMC 的存储目前已经有一部分国内厂商可以替代，但是 Oracle 的江湖老大地位却无人撼动。

即使把一个数据库的设备做到最贵最好，单个设备出故障的情况还是存在，比如停电。所以数据库的系统一定需要一个备库，而与此同时引发的另外一个问题就是主备同步。

但是传统关系数据库在理论上却根本做不到主备同步。如果你一定要做到同步，那么就意味着每一笔事务都得从主库同步到备库，备库确认后才能应答客户。假如这中间网络出现问题，或者备库存在问题，所有的同步都会被堵塞，也就是所有的写操作都无法进行。

对于银行和企业来说，这是一个生死两难的问题，要保证同步，就面临着业务不可用的风险。所以银行购买可靠性更高的存储和服务器等硬件。最好的硬件可靠性自然高，可是价钱也非常高昂。

传统关系数据库的另外一个局限就是分布式数据库的缺失。分布式事务两阶段提交模型看起来相当美好，但是实际上一旦节点在第二阶段出现故障，则事务既无法提交也无法回滚，只能被挂起，在实际生产系统中，这会导致数据库的连接迅速被耗尽，从而使得服务中断。

分布式数据库的缺失导致传统关系数据库无法进行水平扩展，而只能采取垂直方式进行扩展，这不仅进一步增加了成本，也限制了业务的发展。

无论是主库备库不一致，还是分布式数据库的缺失，根本的原因是传统关系数据库自身高可用的缺失，即今天的传统关系数据库都是通过外部硬件来保证可用性，而没有从数据库系统内部来解决问题。

OceanBase 的目标：十倍性价比，做到别人做不到的事

关系数据库的市场是如此之特殊，OceanBase 想要生存和发展，就必须在一些点上做到极致。而 OceanBase 给自己定的目标就是：把性价比做到传统数据库的十倍，并且做到别人做不到的事。

OceanBase 负责人阳振坤

从八年前立项至今，OceanBase 一直在脚踏实地的做三件事。

1）第一件事情是保证高可用的同时解决数据一致性问题。OceanBase 通过把可用性做到数据库系统内部来解决这个问题。前面我们分析过，高可用与主备库数据一致的矛盾，这是一个无法改变的客观规律。那么，OceanBase 是如何做到的？

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

以三个库为例，如果坏了一台机器，每一笔事务至少会在剩下两台中的一台上出现，所以整个系统能够很快的恢复起来，继续提供服务。这样既保证了数据一致性，又保证了整个系统的可行性。

如果万一坏了两台怎么办？虽然同时坏两台机器的概率极其低，但是在实际生产中还是可能出现的。所以，在重要的生产系统中，OceanBase 用的不是三个库，而是五个库。这也就意味着，即使坏了一台机器，哪怕人为因素导致再杀掉一台，这个系统仍然能够正常工作。

高可用和数据的一致性，OceanBase 让两者都得到了保证。这也就是我们说的，做别人做不到的事。OceanBase 可以跟银行保证：少量服务器甚至机房故障不会丢失任何一笔数据，也不会停止服务，甚至人工对账的手段也不再需要。这也是今天银行业非常欢迎我们的原因之一。

2）第二件事是提升性能，OceanBase 通过原生的读写分离，使得整个系统性能，特别是写的性能得到了很大的提升，同时将成本大幅度降低。

OceanBase 将新写入的数据放在内存，使得整个写事务（除了日志）不需要随机写盘。这对性能来说有了质的提升。

但是原生的读写分离，其实是有成本的。一个成本就是需要把新的修改放到内存之中，内存容量是有限的，不可能无穷无尽地写下去。所以每隔一段时间一定要把这个内容融合到磁盘中去。

虽然本质上还是需要把数据写到磁盘里，但是带来的好处是显著的。通过原生的读写分离可以完美错开业务的高峰期。把业务高峰期要做的事情（写盘）先放在内存之中，那么等过了高峰期，在平峰期和低谷期时，再把数据写到硬盘里去，相当于把 CPU、硬盘 IO 错开利用。

3）第三件事就是我们真的把 OceanBase 做成了一套分布式数据库。

有人会说这个看起来很简单，不就是把在一台机器上做的事在几台机器上运行吗？OceanBase 几十个人的团队花了整整五年，做了三个大的版本，才把分布式事务做到了如今比较完善的地步。

分布式的意义究竟何在呢？双十一一年就一次，对于业务量稳定的银行和企业而言，有人觉得这个不是必要的需求。

但现如今，移动支付已经融入到了每个人的生活。一个非常普遍的业务高峰期就真实发生在每个工作日的中午，上班族们拿着手机支付餐费，随着手机支付的进一步普及，这个常态的支付峰值会越来越高。

未来已来，砥砺前行

OceanBase Milestone

2010 年 6 月，OceanBase 正式立项；2011 年，淘宝收藏夹上线；2014 年，支付宝交易系统上线；2016 年，支付宝账务系统上线；2017 年，OceanBase 开始商业银行推广，至今已在多家商业银行上线运行。

OceanBase 至今已成功应用于支付宝全部核心业务：交易、支付、会员和账务等系统，网商银行和印度 PayTM 以及阿里巴巴淘宝收藏夹、P4P 广告报表等业务。从 2017 年开始，OceanBase 开始服务外部客户，包括南京银行、浙商银行、人保健康险平台等。

下一步方向

OceanBase 2.0 即将在这个夏天发布，这是 OceanBase 真正把分布式事务做的比较完善的一个版本。2.0 版本中同时会在事务优化、SQL 优化器上做更多提升。

同时，后续我们希望通过人工智能/机器学习来协助用户更好的使用数据库，包括二级索引，SQL 性能优化，故障诊断等等。我们也使用包括 RDMA 在内的新技术，以便进一步提升系统的性能，降低总体的成本。

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/vjx9-7Ribwu_rUM_j7tseA