亿级订单数据分库分表设计方案（含整体架构图）

根据业务初步预估订单业务量，每天5千万的数据。我们将订单数据划分为了2大类型：分别为热数据和冷数据。

根据实际业务场景，用户基本不会操作或查询2个星期以上的数据，如果这部分数据存储在DB中，那么成本会非常高，而且也不方便维护。另外，如果有特殊情况需要访问归档数据，可以走离线数据查看。

对于这2类数据，规划如下：

热数据：使用MySQL进行存储，分库分表；

冷数据：ES 或 TiDB或Hive存储；

MySQL 分库分表

1. 按业务拆分

在业务初始阶段，为了加快应用上线和快速迭代，很多应用都采用集中式的架构。但是随着业务系统的扩大，系统越来越复杂，越来越难以维护，开发效率变得越来越低，并且对资源的消耗也变得越来越大，通过硬件提高系统性能的成本会变得更高。

订单库也可以根据不同的业务场景，如大客户订单、散客订单等等，进行DB拆分。

将不同的业务放到不同的库中，将原来所有压力由同一个库中分散到不同的库中，提升了系统的吞吐量。

2. 分表策略

在订单表中，order_id 允许重复，可以将该字段作为sharding key。假设单个库需要分配 10 张表可以满足业务需要，可以简单地取模计算出订单分配到哪张表。

一旦确定sharding key，就只能根据sharding key定位到子表进而查询该子表下的数据；如果确实想根据user_id 去查询相关订单，那么需要先根据user_id 查询映射到的order_id list，然后再根据order_id list 再查询。

3. 分库策略

数据库分表能够解决单表数据量很大的时候数据查询的效率问题，但是无法给数据库的并发操作带来效率上的提高，因为分表的实质还是在同一个数据库Server上进行的操作，很容易受数据库Server IO 性能的限制。

因此， 可以将数据进行分库操作，可以解决单台数据库Server的性能瓶颈。

分库策略与分表策略的实现很相似，最简单的都是可以通过取模的方式进行路由。

如果order_id 不是整数类型，可以先hash 在进行取模，如 hash(order_id) % DB数量。

4. 分库分表结合使用策略

数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。有时候，我们需要同时考虑这两个问题，因此，我们既需要对单表进行分表操作，还需要进行分库操作，以便同时扩展系统的并发处理能力和提升单表的查询性能，就是我们使用到的分库分表。

如果分库和分表都使用同一个拆分键进行 Sharding 时，根据拆分键的键值按总的分表数（分库数x分表数）取余。

例如，有 2 个分库，每个分库 4 张分表，那么 0 库上保存分表 0~3，1 库上保存分表 4~7。某个键值为 15，15 % (2 * 4) = 7，所以 15 被分到 1 库的表 7 上。

整体架构图

将订单请求分为查询和更新请求，更新请求比较简单，就是根据分库分表规则写入db即可。

对于查询请求，我们需要计算出查询的是热数据还是冷数据，根据查询的时间范围计算出查询的是热数据还是冷数据。或者无法确定热数据、冷数据，就都走ES 或TiDB。

另外架构图中的冷数据指的是近期1年的数据，如果是查询一年前的数据，建议直接离线查hive即可。

图中有一个定时Job，主要用来定时迁移订单数据，需要将冷数据分别迁移到ES和hive中。