小米以及当前公司分库分表的实践-CSDN博客

本文链接：https://blog.csdn.net/hbnn111/article/details/135986930

本文目录：

介绍什么是分库分表；

为什么要分库分表；

怎么做分库分表，小米是如何实现的；如何进行数据迁移。

分库分表遇到的问题；

分库分表的下一代解决方案；

介绍什么是分库分表，为什么要分库分表

介绍分库分表之前，要说下数据库架构的演进过程。最早的数据库是单体应用，和我们的业务系统部署在同一个机器上。随着业务发展，数据库和业务系统分开部署，大量的读请求会触发高频次的随机IO，这在一定程度上影响了写请求，且我们的业务几乎都是读多写少，因此数据库演变成了一主多从（也有多主多从，但常用的还是一主多从）的部署方式，且实现了读写分离。写只写主库，读只读从库。架构类似如下：

小米之前基于开源KingShard中间件做了一层代理，客户端发起请求后，代理会解析SQL，根据sql类型以及是否有显示指定主库来决定应该把请求发给主库还是从库。如：

"select /*master*/ * from table" 显示读主库，默认读从库。

读写分离一定程度上分摊了高并发请求和检索性能，但如果单库或者单表的数据量过大，其TPS/QPS以及查询能力都会下降。下面是我们现在一个业务系统的几张表，都几十G了。

下面是数据库健康状况监控的例子：

当单库或者单表的数据量过大时，无论如何进行性能调优（重建索引，优化SQL等，增加单机配置），都无法改变当前的读请求的性能，此时单DB的性能已经达到了瓶颈。如果读写请求频次不高，可以忍一忍。但如果还是读写非常频繁的业务，特别是高并发场景下，基本上整个业务会受到DB的拖累，严重的会导致整个系统崩溃。此时，就要考虑进行分库分表了。

分库分表的基本思想就是将之前揉在一个机器上的库和表根据某种规则进行拆分，将单表数据分散到多个字库或者多张表上，不同的库表会部署在不同的机器上，从而减轻单个节点的压力。类似下图，单张1000w条的数据表，根据某个规则拆分成10张表：

怎么做分库分表

拆分方式

拆分方式包括两种：垂直拆分和水平拆分

1）垂直拆分

垂直拆分主要是拆库，根据业务功能区划分，比如在电商系统中订单，商品，库存，履约，风控等业务应该使用独立的数据库。记得在2018年，那时我们后端所有业务的数据表都在一个库中，有个负责拼团的同学在自己代码中引入了一个bug，大概逻辑是遍历所有用户并在每个循环内都执行一次慢查询，用户数量应该有几十万。不出意外，在618的时候，系统崩掉了，导致30分钟都下不了单。导致出现问题的根本原因就是其他业务的慢查询拖垮了DB，从而影响了使用同一个DB的其他业务，尤其是下单，这简直是个灾难。因此，我们痛定思痛，开始进行拆库，各个业务线逐步将数据库拆分出去。

垂直分库

垂直拆分是和分布式系统相辅相成的，微服务的建立的前提应该就是底层数据源的隔离，否则毫无意义。那么垂直拆分的原则在上面也说了，要根据业务去划分，这个地方倒是不复杂。

2）水平分库分表

水平拆分包括既分库又分表，也可以不分库只分表，两种方式的目的都是将单张表数据分散到多个分表，每个分表的数量成倍减少，从而减轻了对单表的读写压力。既分库又分表的做法是不仅仅分表，还要根据一定规则分到不同的库中，不同的库可以部署在不同的机器上。相比于只分表不分库的做法，分库分表可以降低单台机器的瓶颈，毕竟单台机器的CPU，内存，磁盘IO，带宽等都是有限的。因此，通常情况下我们都会采用分库分表的做法。