大型互联网公司订单库分区分表优化实践

背景

原订单表的数据量巨大，且业务要求查询维度较多，即使加了两个从库，优化索引，仍然存在很多查询不理想的情况。去年大量抢购活动的开展，使数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求。

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

垂直切分

垂直切分是最容易想到也最容易实施的方法，先将原有的订单库分为基础订单库、订单流程库，这里不再展开。

水平切分

随着数据量、并发量和查询复杂度的持续增加，垂直拆分的瓶颈很快就出现了。这个时候需要一套新的订单模型(在不同业务场景下模型不同，拆分的方法也不同，但是思路基本一致)。为同时满足C端用户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA（我们内部开发的MySQL binlog实时解析服务）同步到一个运营库。

切分策略

1. 查询切分

将ID和库的Mapping关系存储在一个单独的DB中。

优点：ID和库的Mapping算法可以根据需要随时调整

缺点：引入额外的单点

2. 范围切分

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

优点：单表大小可控，水平扩展方便

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

3. Hash切分

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

数据水平切分后目标是易于水平扩展的，考虑采用mod 2^n这种一致性Hash

以统一订单库为例，分库分表的方案是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比较类似，这里不再赘述。

唯一ID方案

主流的方法有那么几种:

1. 数据库自增ID

优点：最简单

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

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

优点：高可用、ID简洁

缺点：需额外数据库集群

3. Twitter Snowflake

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

缺点：需额外的集群以及ZK

4. GUID、Random算法

优点：简单

缺点：生成ID较长，有重复几率

我们的方案

为了减少运营成本并减少额外的风险我们排除了所有需要独立集群的方案，采用了带有业务属性的方案：

时间戳+用户标识码+随机数

有下面几个好处：

• 方便、成本低。
• 基本无重复的可能。
• 自带分库规则，这里的用户标识码即为用户ID的后四位，在查询的场景下，只需要订单号就可以匹配到相应的库表而无需用户ID，只取四位是希望订单号尽可能短，并且根据需求评估下来四位已经足够。
• 可排序，因为时间戳在最前面。

缺点是长度稍长，性能要比int/bigint的稍差等。

其它问题

• 事务支持：我们是将整个订单领域聚合体切分，维度一致，所以对聚合体的事务是支持的。
• 复杂查询：垂直切分后，就跟join说bye bye；水平切分后，查询的条件一定要在切分的维度内，比如查询具体某个用户下的订单等；禁止不带切分的维度的查询，即使中间件可以支持这种查询，可以在内存中组装，但是这种需求往往不应该在在线库查询，或者可以通过其它方法转换到切分的维度来实现。

总结

并非所有表都需要水平拆分，要看增长的类型和速度见招拆招。毕竟水平拆分后会增加开发的复杂度，不到万不得已不使用。

在大规模并发的业务上，尽量做到在线查询和离线查询隔离，交易查询和运营/客服查询隔离。

拆分维度的选择很重要，要尽可能在解决拆分前问题的基础上，便于开发。

数据库没你想象的那么坚强，需要保护，尽量使用简单的、良好索引的查询，这样数据库整体可控，也易于长期容量规划以及水平扩展。