背景与挑战

订单单表大小早已突破 200GB，由于查询维度较多，即使增加了两个从库并优化了索引，仍然存在很多查询性能不理想的情况。随着去年大量抢购活动的开展，数据库达到瓶颈，应用只能通过限速、异步队列等机制对其进行保护。此外，业务需求层出不穷，原有的订单模型很难满足新的业务需求，但基于原订单表的 DDL 变更非常吃力，无法达到业务要求。

随着这些问题越来越突出，订单数据库的切分变得愈发急迫。这次切分的目标是：未来十年内不需要担心订单容量的问题。

总体架构演进

垂直切分

先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等（本文不再展开详述）。

垂直切分
垂直切分示意图

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

水平切分

原有的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型。为同时满足 C 端用户、B 端商户、客服、运营等多方需求，我们分别通过 用户 ID 和 商户 ID 进行切分，并通过 PUMA（我们内部开发的 MySQL binlog 实时解析服务）同步到一个运营库。

水平切分
水平切分示意图

分库分表策略

1. 查询切分

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

查询切分
查询切分示意图

  • 优点：ID 和库的 Mapping 算法可以随意更改。
  • 缺点：引入额外的单点风险。

2. 范围切分

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

范围切分
范围切分示意图

  • 优点：单表大小可控，天然支持水平扩展。
  • 缺点：无法解决集中写入瓶颈的问题。

3. Hash 切分

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

hash 切分
Hash 切分示意图

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

以统一订单库为例，我们分库分表的方案是 32 * 32 的：

  1. 通过 UserId 后四位 mod 32 分到 32 个库中。
  2. 同时将 UserId 后四位 Div 32 Mod 32，将每个库分为 32 个表。
  3. 共计分为 1024 张表。

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

为什么这种方式易于水平扩展？

我们分析如下两个场景：

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

  • 方法一：按照现有规则不变，可以直接扩展到 32 个数据库集群。
    扩展方法
    扩展方法一
  • 方法二：如果 32 个集群也无法满足需求，那么将分库分表规则调整为 (32 * 2^n) * (32 / 2^n)，可以达到最多 1024 个集群。
    扩展方法
    扩展方法二

场景二：单表容量达到瓶颈（或者 1024 张表无法满足需求）

  • 方法：
    扩展方法
    扩展方法三

假如单表都已突破 200GB，200 * 1024 = 200TB（按照现有的订单模型估算，大概一万千亿订单，相信这一天指日可待）。没关系，采用 32 * (32 * 2^n) 策略，这时分库规则不变，单库里的表再进行裂变。

当然，在目前订单这种规则下（用 UserId 后四位 mod）还是有极限的，因为只有四位，所以最多拆 8192 个表。至于为什么只取后四位，后面会有篇幅讲到。

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

唯一 ID 生成方案

这个方案很多，主流的有以下几种：

1. 利用数据库自增 ID

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

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

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

3. Twitter Snowflake

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

4. 一大波 GUID、Random 算法

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

我们的方案

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

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

有下面几个好处：

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

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

其他关键问题

  • 事务支持：我们是将整个订单领域聚合体切分，维度一致，所以对聚合体的事务是支持的。

  • 复杂查询：

    • 垂直切分后，就跟 Join 操作说拜拜了。
    • 水平切分后，查询的条件一定要在切分的维度内，比如查询具体某个用户下的各位订单等。
    • 禁止不带切分维度的查询。即使中间件可以支持这种查询（可以在内存中组装），但是这种需求往往不应该在在线库查询，或者可以通过其他方法转换到切分的维度来实现。

数据迁移方案

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

第一阶段

数据迁移
数据迁移第一阶段

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

第二阶段

数据迁移
数据迁移第二阶段

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

第三阶段

数据迁移
数据迁移第三阶段

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

总结与建议

  • 并非所有表都需要水平拆分，要看增长的类型和速度。水平拆分是重量级方案，拆分后会增加开发的复杂度，不到万不得已不使用。
  • 在大规模并发的业务上，尽量做到在线查询和离线查询隔离，交易查询和运营/客服查询隔离。
  • 拆分维度的选择很重要，要尽可能在解决拆分前问题的基础上，便于开发。
  • 数据库并非坚不可摧，需要保护。尽量使用简单的、良好索引的查询，这样数据库整体可控，也易于长期容量规划以及水平扩展。
说明：本文基于 2016 年左右的技术实践整理，文中提到的内部工具（如 PUMA）及具体架构参数仅供参考，实际场景请根据当前业务规模与技术栈进行调整。