数据库分库分表策略实现方案！

淡淡的烟草味﹌ 2022-05-12 10:00 226阅读 0赞

**一、MySQL扩展具体的实现方式**

随着业务规模的不断扩大，需要选择合适的方案去应对数据规模的增长，以应对逐渐增长的访问压力和数据量。

关于数据库的扩展主要包括：**业务拆分、主从复制，数据库分库与分表**。这篇文章主要讲述数据库分库与分表

**（1）业务拆分**

在 《[大型网站应用之海量数据和高并发解决方案总结一二][Link 1] 》一篇文章中也具体讲述了为什么要对业务进行拆分。

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

因此，在选型初期，一个优良的架构设计是后期系统进行扩展的重要保障。

例如：电商平台，包含了用户、商品、评价、订单等几大模块，最简单的做法就是在一个数据库中分别创建users、shops、comment、order四张表。

![70][]

但是，随着业务规模的增大，访问量的增大，我们不得不对业务进行拆分。每一个模块都使用单独的数据库来进行存储，不同的业务访问不同的数据库，将原本对一个数据库的依赖拆分为对4个数据库的依赖，这样的话就变成了4个数据库同时承担压力，系统的吞吐量自然就提高了。

![70 1][]

**（2）主从复制**

1、MySQL5.6 数据库主从（Master/Slave）同步安装与配置详解：

http://blog.csdn.net/xlgen157387/article/details/51331244

2、MySQL主从复制的常见拓扑、原理分析以及如何提高主从复制的效率总结：

http://blog.csdn.net/xlgen157387/article/details/52451613

3、使用mysqlreplicate命令快速搭建 Mysql 主从复制：

http://blog.csdn.net/xlgen157387/article/details/52452394

上述三篇文章中，讲述了如何配置主从数据库，以及如何实现数据库的读写分离，这里不再赘述，有需要的选择性点击查看。

![70 2][]

上图是网上的一张关于MySQL的Master和Slave之间数据同步的过程图。

主要讲述了MySQL主从复制的原理：数据复制的实际就是Slave从Master获取Binary log文件，然后再本地镜像的执行日志中记录的操作。由于主从复制的过程是异步的，因此Slave和Master之间的数据有可能存在延迟的现象，此时只能保证数据最终的一致性。

**（3）数据库分库与分表**

我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是通过添加更多的机器来共同承担压力。

我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求？因此，使用数据库的分库分表，能够立竿见影的提升系统的性能，关于为什么要使用数据库的分库分表的其他原因这里不再赘述，主要讲具体的实现策略。请看下边章节。

## **二、分表实现策略** ##

***关键字：用户ID、表容量***

对于大部分数据库的设计和业务的操作基本都与用户的ID相关，因此使用用户ID是最常用的分库的路由策略。用户的ID可以作为贯穿整个系统用的重要字段。因此，使用用户的ID我们不仅可以方便我们的查询，还可以将数据平均的分配到不同的数据库中。（当然，还可以根据类别等进行分表操作，分表的路由策略还有很多方式）

接着上述电商平台假设，订单表order存放用户的订单数据，sql脚本如下（只是为了演示，省略部分细节）：

![70 3][]

当数据比较大的时候，对数据进行分表操作，首先要确定需要将数据平均分配到多少张表中，也就是：**表容量**。

这里假设有100张表进行存储，则我们在进行存储数据的时候，首先对用户ID进行取模操作，根据 `user_id%100` 获取对应的表进行存储查询操作，示意图如下：

![70 4][]

例如，`user_id = 101` 那么，我们在获取值的时候的操作，可以通过下边的sql语句：

> select \* from order\_1 where user\_id= 101

其中，`order_1`是根据 `101%100` 计算所得，表示分表之后的第一章order表。

***注意：***

在实际的开发中，如果你使用MyBatis做持久层的话，MyBatis已经提供了很好得支持数据库分表的功能，例如上述sql用MyBatis实现的话应该是：

接口定义：

![70 5][]

xml配置映射文件：

![70 6][]

其中`${tableNum}` 含义是直接让参数加入到sql中，这是MyBatis支持的特性。

*注意：*

> *另外，在实际的开发中，我们的用户ID更多的可能是通过UUID生成的，这样的话，*
> 
> *我们可以首先将UUID进行hash获取到整数值，然后在进行取模操作。*

## **三、分库实现策略** ##

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

因此，如何将数据库IO性能的问题平均分配出来，很显然将数据进行分库操作可以很好地解决单台数据库的性能问题。

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

还是上例，将用户ID进行取模操作，这样的话获取到具体的某一个数据库，同样关键字有：

***用户ID、库容量***

路由的示意图如下：

![70 7][]

上图中库容量为100。

同样，如果用户ID为UUID请先hash然后在进行取模。

## **四、分库与分表实现策略** ##

上述的配置中，数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。

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

分库分表的策略相对于前边两种复杂一些，一种常见的路由策略如下：

> １、中间变量　＝ user\_id%（库数量\*每个库的表数量）;
> 
> ２、库序号　＝　取整（中间变量／每个库的表数量）;
> 
> ３、表序号　＝　中间变量％每个库的表数量;

例如：数据库有256 个，每一个库中有1024个数据表，用户的user\_id＝262145，按照上述的路由策略，可得：

> １、中间变量　＝ 262145%（256\*1024）= 1;
> 
> ２、库序号　＝　取整（1／1024）= 0;
> 
> ３、表序号　＝　1％1024 = 1;

这样的话，对于user\_id＝262145，将被路由到第０个数据库的第１个表中。

示意图如下：

![70 8][]

## **五、分库分表总结** ##

关于分库分表策略的选择有很多种，上文中根据用户ID应该是比较简单的一种。其他方式比如使用号段进行分区或者直接使用hash进行路由等。有兴趣的可以自行查找学习。

关于上文中提到的，如果用户的ID是通过UUID的方式生成的话，我们需要单独的进行一次hash操作，然后在进行取模操作等，其实hash本身就是一种分库分表的策略，使用hash进行路由策略的时候，我们需要知道的是，也就是hash路由策略的优缺点，优点是：数据分布均匀；缺点是：数据迁移的时候麻烦，不能按照机器性能分摊数据。

上述的分库和分表操作，查询性能和并发能力都得到了提高，但是还有一些需要注意的就是，例如：原本跨表的事物变成了分布式事物；由于记录被切分到不同的数据库和不同的数据表中，难以进行多表关联查询，并且不能不指定路由字段对数据进行查询。分库分表之后，如果我们需要对系统进行进一步的扩阵容（路由策略变更），将变得非常不方便，需要我们重新进行数据迁移。

--------------------

最后需要指出的是，分库分表目前有很多的中间件可供选择，最常见的有MyCat、sharding-sphere等。

另外Spring也可以实现数据库的读写分离操作，后边的文章，会进一步学习。

## **六、总结** ##

上述中，我们学到了如何进行数据库的读写分离和分库分表，那么，是不是可以实现一个可扩展、高性能、高并发的网站那？很显然还不可以!一个大型的网站使用到的技术远不止这些，可以说，这些都是其中的最基础的一个环节，因为还有很多具体的细节我们没有掌握到，比如：数据库的集群控制，集群的负载均衡，灾难恢复，故障自动切换，事务管理等等技术。因此，还有很多需要去学习去研究的地方。

[Link 1]: http://mp.weixin.qq.com/s?__biz=MzUxNTU4NjAwMw==&mid=2247483652&idx=1&sn=cea371958a5173e39b0c0dd73f212ed8&chksm=f9b523b8cec2aaae3a5f47f8d6f3ea870a37de8c8b4769c5c60a4a674d9ceffc7e00041b2549&scene=21#wechat_redirect
[70]: /images/20220512/6e006344657648d795a17e70cd088e6d.png
[70 1]: /images/20220512/e437bb202e1846938281d4b9868b1229.png
[70 2]: /images/20220512/1c488f23051c496c9ad9d1ab7a9dc4b3.png
[70 3]: /images/20220512/585574c399a14046963f4b64e86aefa1.png
[70 4]: /images/20220512/14ee63b808a84bc3a28acd2cafc6bfd8.png
[70 5]: /images/20220512/5c5bd63889f5440b8e00f862975c6bd0.png
[70 6]: /images/20220512/1b718b8bd41e416f96146f003b945497.png
[70 7]: /images/20220512/21e1d8bc2ab344cfb0fd4b130f5e60e9.png
[70 8]: /images/20220512/f760598cb47f423fb7cafeac36570fa4.png