转：Java订单系统分库分表实践及mycat分表分库的原理。

青旅半醒 2022-10-02 05:58 236阅读 0赞

# 引言 #

从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。

数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

# 垂直切分 #

先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，本文就不展开讲了。

![Image 1][]

# 水平切分 #

垂直切分缓解了原来单集群的压力，但是在抢购时依然捉襟见肘。原有的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型，为同时满足C端用户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA同步到一个运营库。

![Image 1][]

## 切分策略 ##

### 查询切分 ###

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

![Image 1][]

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

### 范围切分 ###

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

![Image 1][]

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

### Hash切分 ###

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

![Image 1][]

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

以统一订单库为例，我们分库分表的方案是32\*32的，即通过UserId后四位mod 32分到32个库中，同时再将UserId后四位Div 32 Mod 32将每个库分为32个表，共计分为1024张表。线上部署情况为8个集群(主从)，每个集群4个库。

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

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

**方法一**

按照现有规则不变，可以直接扩展到32个数据库集群。

![Image 1][]

**方法二**

如果32个集群也无法满足需求，那么将分库分表规则调整为(32\*2^n)\*(32/2^n)，可以达到最多1024个集群。

![Image 1][]

**场景二：单表容量达到瓶颈（或者1024已经无法满足你）**

方法：

![Image 1][]

假如单表都已突破200G，200\*1024=200T（按照现有的订单模型算了算，大概一万千亿订单，相信这一天，嗯，指日可待！），没关系，32\*(32\*2^n)，这时分库规则不变，单库里的表再进行裂变，当然，在目前订单这种规则下（用userId后四位 mod）还是有极限的，因为只有四位，所以最多拆8192个表，至于为什么只取后四位，后面会有篇幅讲到。

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

### 唯一ID方案 ###

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

**利用数据库自增ID**

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

**利用数据库集群并设置相应的步长**

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

**Twitter Snowflake**

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

**一大波GUID、Random算法**

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

### 我们的方案 ###

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

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

有下面几个好处：

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

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

### 其他问题 ###

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

**数据迁移**

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

*  第一阶段

![Image 1][]

数据库双写（事务成功以老模型为准），查询走老模型。

每日job数据对账（通过DW），并将差异补平。

通过job导历史数据。

*  第二阶段

![Image 1][]

历史数据导入完毕并且数据对账无误。

依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型。

每日job数据对账，将差异补平。

*  第三阶段

![Image 1][]

老模型不再同步写入，仅当订单有终态时才会异步补上。

此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待DW改造完就可以完全废除老模型了。

# mycat #

## mycat是怎样实现分库分表的？ ##

mycat里面通过定义路由规则来实现分片表（路由规则里面会定义分片字段，以及分片算法）。分片算法有多种，你所说的hash是其中一种，还有取模、按范围分片等等。在mycat里面，会对所有传递的sql语句做路由处理（路由处理的依据就是表是否分片，如果分片，那么需要依据分片字段和对应的分片算法来判断sql应该传递到哪一个、或者哪几个、又或者全部节点去执行）

## mycat适用于哪些场景？相对于海量存储的Nosql的适用场景又如何？ ##

数据量大到单机hold不住，而又不希望调整架构切换为NoSQL数据库，这个场景下可以考虑适用mycat。当然，使用前也应该做规划，哪些表需要分片等等。另外mycat对跨库join的支持不是很好，在使用mycat的时候要注意规避这种场景。

转载：[https://www.jianshu.com/p/4f019cce16f5][https_www.jianshu.com_p_4f019cce16f5]

[Image 1]: 
[https_www.jianshu.com_p_4f019cce16f5]: https://www.jianshu.com/p/4f019cce16f5