支付宝双11的功臣-分布式关系型数据库（oceanbase）

咱们都知道阿里双11，除了创造了世界史上的交易奇迹以外，也创造了世界技术史上的奇迹。支付宝的峰值达到了每秒12万笔，这在技术界简直是一个奇迹。为何说他是一个奇迹呢？简单的来解释一下：其实在平常开发中，打交道最多的就是数据库，好多开发都戏称只会增、删、改。可是千万不要小看增、删、改，由于假设你只有一个用户访问的你的数据库，你怎么写均可以，可是若是有几十万，上百万，上千万，乃至上亿用户呢？若是操做不当，那么你的数据库必定会down掉。因此看上去简单的东西其实一点都不简单，就好像风清扬同样，简单的剑招却蕴含着上千变化。

这里，我主要想揭秘下oceanbase，由于整个支付宝的交易的库都是依赖于它。oceanbase到底是什么？用官方的话是这样的：OceanBase是一个支持海量数据的高性能分布式数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务，由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。那么之前在没有使用ob以前，支付宝都用的什么呢？mysql或者oracle。这两个一个是开源的数据库，一个是甲骨文公司的商业付费数据库。简单的来讲都是人家老外搞得！其实这两个数据库已经很强大了，支付宝之前的框架都是基于这两种数据库的。可是随着业务的发展，这两种数据库也带来了弊端。

-------------------------------------------------------------华丽的分割线-------------------------------------------------------------

假设咱们要撑起上千万的并发量，上百PB，乃至TB的数据量。如何设计？

方案1、单库（热备）

这个方案彻底不行，缘由很少说了。

方案2、数据拆分（分库分表）

按照业务特色将数据拆分：

垂直拆分以及水平拆分------好比说利用用户的user_id经过hash取模，而后路由到不一样的分区。

这么作带来的问题有两个：一、当数据/负载增长时，须要人工介入，代价很是大。

二、select查询有时候须要便利全部的分区，速度很是慢。

三、每一台机器都要主从同步，管理起来太麻烦。

方案3、参考google的bigtable

主要是将一个bigtable拆分红几百万个子表（主键有序）。

好处：一、数据不会丢失(hdfs)，故障迁移，可扩展。二、子表有序，查询快。

这样的话，方案就生成了，参考bigtable，在hbase的开源基础上本身开发一套。后来通过验证发现不行，由于，首先hbase的开源不完全，每台单机支持的数据有限，而后是必须引入分布式事务2PC，通常时间在2~5s左右，由于对于hbase这种nosql只保证单行事务，若是要跨行跨表操做是支持不了的。而且分布式事务太耗时，因此这个方案只能抛弃！

在设计oceanbase的时候，目标是支持10w+tps，100w+qps，100TB+数据，难道没有方案了么？-------------------------------------------------------------华丽的分割线-------------------------------------------------------------

既要有非关系数据库的海量数据存储，还要有关系型数据库的事务，到底如何该解决呢？

通过数据分析，发现了隐藏在数据中的一个秘密：虽然业务线的数据量庞大，可是修改量实际不多。这个怎么理解。

我打个比喻：

一、人口基数实际上很是大，可是考虑到出生/死亡/失踪，这部分人口实际上在总人口中占比很小。

二、金融帐务系统天天要记录不少的流水，可是考虑到一半在线上保存一年的流水，那么天天新增的几乎占比很小。

三、金融交易系统天天虽然要记录不少交易，可是考虑到一半都保存一年以上的交易记录，那么新增的占比很小的。

这就是隐藏在数据中的秘密！

其实大部分的数据，都是基数大，新增，删除，修改量占比不大。

那么能够这么解决。采用单台服务器记录最近一段时间的修改增量（内存中记录），而之前的数据不变（基线数据）。写事务只在单台服务器写，避免了2PC，高效的实现了跨行跨表事务。而后按期合并修改增量到基线数据服务器。

-------------------------------------------------------------华丽的分割线-------------------------------------------------------------

基于上面描述，OB整个系统架构：

 

 

整个ob集群包括：rootserver，updateserver，chunkserver，mergeserver这几个类服务器。

client：与mysql兼容，协议相同。

rootserver：管理集群，子表，数据分布，副本。分为主，副（主备数据同步）

updateserver：存储ob中的增量数据（内存）主备

chunkserver：存储基线数据

mergeserver：接受sql，解析，优化，转发给chunkserver或者updateserver，合并结果给客户端。

接下来咱们来深刻探讨一下：

首先ob部署在多个机房，每一个机房一个ob集群。

客户端的请求过程：

一、请求rootserver获取ob集群中的mergeserver列表

二、按照必定策略选择mergeserver

三、请求失败后，从新选择一台mergeserver，若是某一台被请求失败超过必定次数，拉黑。

oceanbase集群会根据路由规则控制流量比，因此不用担忧负载的问题。

ob中的基线数据按照主键排序(查询很是快)并划分为子表（每个256M），而且都有副本。而在rootserver中记录了每一个子表在chunkserver的位置。

 

 

mergeserver会缓存子表的分部信息，根据请求转发给该子表所在的chunkserver，若是写操做还会转发给updateserver。

在chunkserver中，通常存储子表，而一个子表由多个sstable过程，每一个sstable的容量4k~64（主键有序）。

合并操做：

oceanbase按期触发合并/数据分发操做，chunkserver会从updateserver中获取一段时间更新的操做。（业务低谷时操做）

updateserver：

更新操做写入内存，当内存数据量超过必定值时，生成快照存储在SSD中。

按期合并/数据分发：把updateserver增量更新分发到chunkserver中。

一、updateserver冻结当前的活跃的内存表（Active Memory），生成冻结内存表，开启新的活跃内存表后，缓存更新操做写入新的活跃内存表。

二、updateserver通知rootserver数据版本变化，rootserver心跳通知chunkserver。

三、每台chunkserver启动按期合并或数据分发，从updateserver获取每一个子表对应的增量更新数据。

为何分为按期合并和数据分发？

按期合并：chunkserver讲本地sstable中的基线数据与冻结内存表中的增量更新数据归并，生成新的sstable。（由于合并操做对服务器性能影响很是大，须要在业务低估时进行）

数据分发：chunkserver将updateserver中的冻结内存表中的增量缓存到本地。（不受业务高峰限制）

以上就是我对ob的原理的总结，其中也看出一些问题，首先updateserver须要很是大的内存，第二为了不单点，应该是主备切换，这里面用了zookeeper中的paxos算法，选举主机。整个ob仍是很是复杂的，若是想深刻探究还须要花费很大的功夫啊！