浅谈支撑起支付宝整个“11-11”的幕后功臣OceanBase数据库
狗蛋的窝 2019-06-26
简介
Tip:本文首发公众号【一名打字员】
据悉，17年的4月份，蚂蚁金服已经宣布，蚂蚁金服及阿里巴巴自研的关系型数据库OceanBase已经支撑起Tmall和淘宝的日常业务需求，成功替换了之前所采用的单机数据库如Oracle或者开源的MySQL。OceanBase作为一个金融级应用，已经做到了可以容纳数百TB以及数千亿条数据的跨表事物，其最大的亮点就是可扩展，未来很可能会成为支持跨域多地的数据中心。
发展历程
阿里巴巴首席DBA冯春培在一次大会中曾分享了阿里数据库的演变历程，其中大致分为几个阶段：
Oracle
04年以前，淘宝是使用的MySQL数据库，众所周知，5.6以前的PHP在数据库方面有着极大的隐患，所以后来开始向ORACLE迁移。据冯春培介绍，04年阿里的数据库经常出现问题，后来，业务超速发展，ORACLE的优化还是承载不了业务的发展，这个时候阿里和淘宝进行了拆分。虽然ORACLE作为一个优质的商业级DB来说，他提供了一个健硕的应用环境，但是也依然无法摆脱上亿级数据操作的困扰。当然我猜，成本上也是一个很大的方面，每年投入的成本都在1千万以上，另外由于当时淘宝内部团队大都很擅长商业DB，能很便捷的配合业务的扩展。
MySQL
07年以后，阿里感受到数据库方面的贫瘠，开始选择在开源数据库上动手脚，这意味着需要放弃熟悉的，重新开始，并将固化思维进行改变。这个时候的MySQL作为开源领域的佼佼者，具有很强的开发易用性以及具有成熟的中间层，这样极大程度的减少了开发难度，底层的数据存储引擎也十分强大。而且，当时国内某银行使用服务商提供的全套产品之后，无法替换，所以阿里彻底向MySQL进行迁移。在长达三年的迁移中，阿里一方面与ORACLE签署了一份采购协议，使得ORACLE的授权可以随意使用，然后另一方面，平稳的推进MySQL的发展，在当时，传统的关系型数据库在扩张方面是没有一个好的解决方案的。
NoSQL,OceanBase
10年，淘宝的大部分业务扩张很快，这些业务通常涉及到安全、交易以及数据的稳定性等问题，DB方面已经完成不了了，这个时候，淘宝开始重新架构自己的系统，据说，在10年头，阿里系里出现了一系列优秀的架构师。而且市面上开始挂起大数据的热风，很多人开始意识到数据的重要性。而大数据主要分为存取数据，挖掘数据和运营数据，数据可广泛作用于各个领域。
这个时候比起昂贵的ORACLE和各种坑坑洼洼的MySQL来说，阿里开始抛弃开始汲取市场上仅有的非关系型数据库和关系型数据库的优点，决定使用自己掌握的核心技术研发出一款自己的数据库。OceanBase可以自动扩展，具有强一致性，能够达到机房级的容灾，最重要的一点，OceanBase能够达到真正的完全不丢数据。
安利
之前也已经提到，MySQL、ORACLE与OceanBase的发展历程，也简单描述了相关的优缺点，在这里也只简单的安利一下OceanBase的特点，其中大部分思路源于@日照(OceanBase)的官方推文。
在这之前，不得不说说MySQL,当我们切换到MySQL上时，通常会有下面几个疑问：
MySQL的容灾解决方案
MySQL的性能数据
MySQL自身稳定性如何
MySQL DDL解决方案
MySQL主备同步延迟以及数据一致性校验
当然，在这里我就不一一解答了，在互联网上有一系列的解决方案，另外我会在后面的文章中陆续给出自己的看法以及相应的解决方案，有兴趣的童鞋也可以私下与我交流交流。
读过《MySQL技术内幕：InnoDB存储引擎》的童鞋都应该知道，MySQL被设计为一个但进程多线程架构的数据库，与SQL Server类似，与Oracle的多进程架构有所不同。大名鼎鼎的InnoDB被ORACLE收购，应用十分广泛，其体系结构主要分为后台线程和内存。后台线程主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据，这时将已修改的数据文件刷新到磁盘文件，同时中途如果出现异常还要能恢复到正常状态。
MySQL后面我们会详细介绍，毕竟也是开源圈内的一杆大旗，说回来我们的OceanBase，从13年的设计到后面15年的崛起，从官方推文来说，OceanBase达到了分布式数据库基本的几个核心部分，一个是查询，一个是存储还有一个就是事务。
事务处理
首先我们得理清数据分布情况，传统的关系型数据库都有一种叫做两级分区表的概念，就是：时间+业务主键。常见的分布式系统中，分区要不就是用哈希或者是范围。OceanBase能够将不同的分区分布到不同的数据库。这是当下传统关系数据库所无法完成的。
OceanBase是如何达到多机的事务呢，这又得分为单分区和多分去的操作。因为操作单个分区就是在一台机器上，也就是使用的一台机器的服务，本质就是一个单机事务。和其他传统数据库的原理差不多，基于导个版本进行并发控制，不同的是，OceanBase做了一些优化例如日志同步以及加入了内存数据库的无锁结构、内存多版本并发控制、SQL编译执行等等。
多个分区则分为两种情况，单服务器和多服务器。由于多个服务器肯定会跨多个观察者，所以OceanBase也对此进行了一系列的优化，而且里面的里面高可用是基于Paxos协议实现的，OceanBase的开发者和Google Chubby系统的发明者也一致认同“Paxos协议实现的高可用机制都是耍流氓”的话语。
分布式查询
OceanBase里有一个ObProxy的代理服务器，功能则就是一个透明转发代理，可以解析SQL，能够识别操作对应的哪一个分区，然后将其转发过去，据说他的性能是能够达到百万级的QPS。内部人员对它的评价就是：
轻量级SQL Parser
高性能异步框架
支持线程本地化
另外。在运维方面，它支持热升级、全链路监控。说到热升级，主要是新老版本发出不同的请求，对应到相应的新老版本提供服务，一段时间后将自动退出。
OceanBase的执行计划主要分为本地计划、远程计划和分布式计划。这样一个SQL请求到了Observer的服务端，经过一系列的解析、重写和优化过程，再由SQL执行器负责执行。
其它
其它OceanBase还有很多很好的优点，虽然它年龄还小，各方面还很稚嫩，比如说他的强一致性和它的高可用的优化，以及等等等等。。
更多的优点可以移步官方推文
思考
据说OceanBase也曾经开源过0.4的版本，但是目前的版本已经和开源中的架构风马牛不相及，也意味着OceanBase肯定是遇到了许多坎坷，但是最终还是遇到了自己的伯乐。虽然许多关键性的指标OceanBase还没有达到，也没有办法在处理互联网实时大数据量的处理进行高度的契合，生态圈也不够完善，但是一切都在起步，就和我们每一个打字员一样，都在成长的路上，We always on the road。
