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

2017-01-06 10:08:34来源:oschina作者:revoid人点击

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


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


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


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


方案一、单库(热备)


这个方案完全不行,原因不多说了。


方案二、数据拆分(分库分表)


按照业务特点将数据拆分:


垂直拆分以及水平拆分------比如说利用用户的user_id通过hash取模,然后路由到不同的分区。


这么做带来的问题有两个:1、当数据/负载增加时,需要人工介入,代价非常大。


2、select查询有时候需要便利所有的分区,速度非常慢。


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


方案三、参考google的bigtable


主要是将一个bigtable拆分成几百万个子表(主键有序)。


好处:1、数据不会丢失(hdfs),故障迁移,可扩展。2、子表有序,查询快。


这样的话,方案就生成了,参考bigtable,在hbase的开源基础上自己开发一套。后来经过验证发现不行,因为,首先hbase的开源不彻底,每台单机支持的数据有限,然后是必须引入分布式事务2PC,一般时间在2~5s左右,因为对于hbase这种nosql只保证单行事务,如果要跨行跨表操作是支持不了的。并且分布式事务太耗时,所以这个方案只能抛弃!


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


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


经过数据分析,发现了隐藏在数据中的一个秘密:虽然业务线的数据量庞大,但是修改量实际很少。这个怎么理解。


我打个比喻:


1、人口基数实际上非常大,但是考虑到出生/死亡/失踪,这部分人口实际上在总人口中占比很小。


2、金融账务系统每天要记录很多的流水,但是考虑到一半在线上保存一年的流水,那么每天新增的几乎占比很小。


3、金融交易系统每天虽然要记录很多交易,但是考虑到一半都保存一年以上的交易记录,那么新增的占比很小的。


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


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


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


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


基于上面描述,OB整个系统架构:

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


client:与mysql兼容,协议相同。


rootserver:管理集群,子表,数据分布,副本。分为主,副(主备数据同步)


updateserver:存储ob中的增量数据(内存)主备


chunkserver:存储基线数据


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


接下来我们来深入探讨一下:


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


客户端的请求过程:


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


2、按照一定策略选择mergeserver


3、请求失败后,重新选择一台mergeserver,如果某一台被请求失败超过一定次数,拉黑。


oceanbase集群会根据路由规则控制流量比,所以不用担心负载的问题。


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

mergeserver会缓存子表的分部信息,根据请求转发给该子表所在的chunkserver,如果写操作还会转发给updateserver。


在chunkserver中,一般存储子表,而一个子表由多个sstable过程,每个sstable的容量4k~64(主键有序)。


合并操作:


oceanbase定期触发合并/数据分发操作,chunkserver会从updateserver中获取一段时间更新的操作。(业务低谷时操作)


updateserver:


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


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


1、updateserver冻结当前的活跃的内存表(Active Memory),生成冻结内存表,开启新的活跃内存表后,缓存更新操作写入新的活跃内存表。


2、updateserver通知rootserver数据版本变化,rootserver心跳通知chunkserver。


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


为什么分为定期合并和数据分发?


定期合并:chunkserver讲本地sstable中的基线数据与冻结内存表中的增量更新数据归并,生成新的sstable。(因为合并操作对服务器性能影响非常大,需要在业务低估时进行)


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


以上就是我对ob的原理的总结,其中也看出一些问题,首先updateserver需要非常大的内存,第二为了避免单点,应该是主备切换,这里面用了zookeeper中的paxos算法,选举主机。整个ob还是非常复杂的,如果想深入探究还需要花费很大的功夫啊!

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台