大众点评订单分库分表实践之路

李华慰 2016-02-25 09:39:26

本文是关于大众点评订单分库分表实践的一个具体分享，包含对订单库的具体切分策略，以及我个人的一些思考。

背景

订单单表早已突破两百G，因查询维度较多，即使加了两个从库，各种索引优化，依然存在很多查询不理想的情况。加之去年大量的抢购活动的开展，数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护。同时业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求。随着这些问题越来越突出，订单数据库的切分就愈发急迫了。

我们的目标是未来十年内不需要担心订单容量的问题。

垂直切分

先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，这篇文章就不展开讲了。

水平切分

垂直切分缓解了原来单集群的压力，但是在抢购时依然捉襟见肘，并且原有的的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型，为同时满足C端用户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA同步到一个运营库。

1、切分策略

1）查询切分

将id和库的mapping关系记录在一个单独的库中：

优点：id和库的mapping算法可以随意更改。

缺点：引入额外的单点。

2）范围切分

比如按照时间区间或id区间来切分。

优点：单表大小可控，天然水平扩展。

缺点：无法解决集中写入瓶颈的问题。

3）hash切分

一般采用mod来切分，下面着重讲一下mod的策略。

数据水平切分后我们希望是一劳永逸或者是易于水平扩展的，所以推荐采用mod 2^n这种一致性哈希

以统一订单库为例，我们分库分表的方案是32*32的，即通过userId后四位mod 32分到32个库中，同时再将userId后四位div 32 mod 32将每个库分为32个表，共计分为1024张表。线上部署情况为8个集群(主从)，每个集群4个库。

为什么说这种方式是易于水平扩展的呢？我们分析如下两个场景：

场景一：数据库性能达到瓶颈

方法一：

按照现有规则不变，可以直接扩展到32个数据库集群。

方法二：

如果32个集群也无法满足需求，那么将分库分表规则调整为(32*2^n)*(32/2^n)，可以达到最多1024个集群。

场景二：单表容量达到瓶颈（或者1024已经无法满足你）

方法：

假如单表都已突破200G，200*1024=200T（按照现有的订单模型算了算，大概一万千亿订单，相信这一天，恩，指日可待！）。没关系，32*(32*2^n)，这时分库规则不变，单库里的表再进行裂变。当然，在目前订单这种规则下(用userId后四位 mod)还是有极限的，因为只有四位，所以最多拆8192个表，至于为什么只取了后四位，后面会有篇幅讲到。

另外一个维度是通过shopId进行切分，规则8*8和userId比较类似，就不再赘述，需要注意的是shop库我们仅存储了订单主表，用来满足shop维度的查询。

2、唯一ID方案

这个方案也很多，主流的有那么几种：

1）利用数据库自增ID

优点：最简单

缺点：单点风险、单机性能瓶颈

2）利用数据库集群并设置相应的步长(Flickr方案)

优点：高可用、ID较简洁

缺点：需要单独的数据库集群

3）Twitter snowflake

优点：高性能高可用、易拓展

缺点：需要独立的集群以及ZK