简述对“分库分表”的简单认识

比眉伴天荒 2021-11-05 08:34 298阅读 0赞

##  简述对“分库分表”的简单认识 ##

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

## 一、为什么要分库分表？（高并发系统中，数据库层面如何设计） ##

其实，分库分表是两回事儿，可能是光分库不分表，也可能是光分表不分库，都有可能。  
我们先来看一个简单的场景。

现在有一个小创业公司，产品注册用户就 20 万，每天活跃用户1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10。

突然，业务发展迅猛，过了几个月，注册用户数达到了 2000 万！每天活跃用户数 100 万！每天单表数据量 10 万条！高峰期每秒最大请求达到 1000！

这时，公司感觉压力已经有点大了。因为每天多 10 万条数据，一个月就多 300 万条数据，现在单表已经几百万数据了，马上就破千万了。但是勉强还能撑着。高峰期请求现在是 1000，线上部署了几台机器，负载均衡搞了一下，数据库撑 1000QPS 也还凑合。但怎么应对用户以及数据接下来的增长呢？

终于，公司用户数达到 1 亿，每天活跃用户数上千万，每天单表新增数据多达 50 万，目前一个表总数据量都已经达到了两三千万了！扛不住啊！数据库磁盘容量不断消耗掉！高峰期并发达到惊人的 5000~8000！系统支撑很困难！

这种情况下就需要分库分表。实际上这是跟着公司业务发展走的，公司业务发展越好，用户就越多，数据量越大，请求量越大，那单个数据库一定扛不住，必须进行优化。

1.  **分表**

上面场景中单表都几千万数据了，肯定扛不住。单表数据量太大，会极大影响sql 执行的性能，到了后面sql会很慢。一般来说，单表到几百万的时候，性能就会相对差一些了，就得分表。

**分表** 就是把一个表的数据放到多个表中，然后查询的时候就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。

1.  **分库**

一般，一个库最多支撑并发 2000，超过这个阈值一定要扩容的，而且一个健康的单库并发值建议保持在每秒 1000 左右，不要太大。我们可以将一个库的数据拆分到多个库中，访问的时候就访问一个库。

## 二、常用的分库分表中间件及其优缺点 ##

比较常见的包括：cobar，TDDL，atlas，sharding-jdbc，mycat。

## 2.1 cobar ##

阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。

## 2.2 TDDL ##

淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。

## 2.3 atlas ##

360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。

## 2.4 sharding-jdbc ##

当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。

## 2.5 mycat ##

基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。

## 2.6 总结 ##

综上，现在其实建议考量的，就是 sharding-jdbc 和 mycat，这两个都可以去考虑使用。

sharding-jdbc 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖；

mycat 这种 proxy 层方案的缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用 sharding-jdbc，client 层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；但是中大型公司最好还是选用 mycat 这类 proxy 层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护 mycat，然后大量项目直接透明使用即可。

## 三、数据库拆分(垂直拆分,水平拆分) ##

水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来扛更高的并发，还有就是用多个库的存储容量来进行扩容。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5MjI5NTY3_size_16_color_FFFFFF_t_70]  
垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。这个其实挺常见的，例如把一个大表拆开，订单表、订单支付表、订单商品表。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5MjI5NTY3_size_16_color_FFFFFF_t_70 1]  
分表，将一个表变成 N 个表，就是让每个表的数据量控制在一定范围内，保证 SQL 的性能。否则单表数据量越大，SQL 性能就越差。一般是 200 万行左右，不要太多，但是也得看具体怎么操作，也可能是 500 万，或者是 100 万。SQL越复杂，就最好让单表行数越少。

## 四、总结 ##

无论分库还是分表，上面说的那些数据库中间件都是可以支持的。就是基本上那些中间件可以做到分库分表之后，中间件可以根据指定的某个字段值，比如说 userid，自动路由到对应的库上去，然后再自动路由到对应的表里去。

针对具体项目里该如何分库分表？一般来说，垂直拆分，可以在表层面来做，对一些字段特别多的表做一下拆分；水平拆分，当并发承载不了，或者是数据量太大，容量承载不了，可以给拆了；分表，其实哪怕是拆到每个库里去，并发和容量都ok了，但是每个库的表还是太大了，那么就得分表，将这个表分开，保证每个表的数据量并不是很大。

其实还有两种分库分表的方式：

1.  按照 range 来分，就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了。
2.  按照某个字段 hash 一下均匀分散，这个较为常用。

按range 来分，好处在于说，扩容的时候很简单，因为只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。

hash 分发，好处在于说，可以平均分配每个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash。值重新分配到不同的库或表。

参考：

1.  https://mp.weixin.qq.com/s/se0NwQvXaWWO1wDJkJN2uQ

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5MjI5NTY3_size_16_color_FFFFFF_t_70]: /images/20211104/98360b158c224b00a1c993ad57dc58c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5MjI5NTY3_size_16_color_FFFFFF_t_70 1]: /images/20211104/00a371e7ae5f460cbe8c1771e24c5144.png