海量订单订单系统的设计（分库分表和分布式唯一ID和数据迁移）

3. Hash切分

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

hash切分

数据水平切分后我们希望是一劳永逸或者是易于水平扩展的，所以推荐采用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比较类似，就不再赘述，需要注意的是Shop库我们仅存储了订单主表，用来满足Shop维度的查询。

唯一ID方案

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

1. 利用数据库自增ID

优点：最简单。 缺点：单点风险、单机性能瓶颈。

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

优点：高可用、ID较简洁。 缺点：需要单独的数据库集群。

3. Twitter Snowflake

优点：高性能高可用、易拓展。 缺点：需要独立的集群以及ZK。

4. 一大波GUID、Random算法

优点：简单。 缺点：生成ID较长，有重复几率。

我们的方案

为了减少运营成本并减少额外的风险我们排除了所有需要独立集群的方案，采用了带有业务属性的方案： > 时间戳+用户标识码+随机数

有下面几个好处：

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

当然也有一些缺点，比如长度稍长，性能要比int/bigint的稍差等。

数据迁移

数据库拆分一般是业务发展到一定规模后的优化和重构，为了支持业务快速上线，很难一开始就分库分表，垂直拆分还好办，改改数据源就搞定了，一旦开始水平拆分，数据清洗就是个大问题，为此，我们经历了以下几个阶段。

第一阶段

数据迁移

• 数据库双写（事务成功以老模型为准），查询走老模型。
• 每日job数据对账（通过DW），并将差异补平。
• 通过job导历史数据。

第二阶段

数据迁移

• 历史数据导入完毕并且数据对账无误。
• 依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型。
• 每日job数据对账，将差异补平。

第三阶段

数据迁移

• 老模型不再同步写入，仅当订单有终态时才会异步补上。
• 此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待DW改造完就可以完全废除老模型了。