行业案例：大众点评万亿级订单库分库分表方案.pdfVIP

原大众点评的订单单表早就已经突破两百G，由于查询维度较多，即使加了两个从库，优化索引，仍然

存在很多查询不理想的情况。

分库分表改造

去年大量抢购活动的开展，使数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；业务需

求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务

要求。随着这些问题越来越突出，订单数据库的切分就愈发急迫了。

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

先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等。

垂直切分

垂直切分示意：

水平切分

垂直切分缓解了原来单集群的压力，但是在抢购时依然捉襟见肘。

原有的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型，为同时满足C端用

户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA（我们内部

开发的MySQLbinlog实时解析服务）同步到一个运营库。

水平切分示意：

切分策略

1.查询切分

将ID和库的Mapping关系记录在一个单独的库中。

查询切分示意图：

优点：ID和库的Mapping算法可以随意更改。

缺点：引入额外的单点。

2.范围切分

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

范围切分示意图：

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

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

3.Hash切分

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

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

以统一订单库为例，我们分库分表的方案是32*32的，即通过UserId后四位mod32分到32个库中，同时

再将UserId后四位Div32Mod32将每个库分为32个表，共计分为1024张表。

线上部署情况为8个集群(主从)，每个集群4个库。

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

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

方法一

按照现有