数据拆分之分库分表

分库分表的愿意

在高并发系统中，系统承载的压力可能来自于很多层面，但是归根结底来讲，有两方面的压力尤为重要，其一是请求压力，另一个就是数据压力。请求压力还比较好处理，通过增加服务的部署设备，增加集群容量，可以较为方便快捷的处理请求压力，但是数据压力相对来说没有那么好处理，所以当业务发展过快的情况下，业务发展过大的情况下，为了降低数据层的压力，分库分表是必要的

分库分表的中间件

cobar

阿里 b2b 团队开发和开源的，属于proxy层方案，早些年还是可以用的，但是最近几年都没更新，基本没人用，差不多是被抛弃的状态，而且不支持读写分离，存储过程，垮库join和分页等操作

TDDL

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

atlas

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

sharding-jdbc

当当开源的，属于client层方案，之前用的还比较多一些，因为SQL语法支持也比较多，没有太多的限制，而且目前推出到了2.0版本，支持分库分表，读写分离，分布式ID生成，柔性事务(最大力努力送达型事务，TCC事务)，而且确实之前使用的公司会比较多一些，现目前的社区也算是比较活跃，现目前也是一个可以选择的方案

Mycat

基于cobar改造的，属于proxy层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，现在最常用的数据库中间件

总结

综上所述，现目前可以去做考量的就是sharding-jdbc和mycat，这个都是可以考虑使用，

sharding-jdbc这种client层方案的优点就是不用部署，运维陈本地，但是如果遇到升级啥的，就需要各个系统重新升级版本在发布

mycat这种proxy层方案的优点在于需要部署，自己及运维一套中间件，运维成本高，但是好处在于多个各项目是透明的，如果遇到升级之类的，都是自己的中间件哪里去升级就可以

数据库的垂直拆分和水平拆分

水平拆分

水平拆分的意思就是，一个标的数据给弄到多个库的多个表里去，但是每个库的表结构都是一样，只不过每个库表放的数据是不同的，所有的库表的数据加起来就是全部数据，水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来扛更高的并发，还有就是用多个库的存储容量来进行扩容

垂直拆分

垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去，每个库表的结构都不一样，每个库表都包含一部分一段，一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另一个表里去，因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存中存储更多的行，性能就越好，这个一般在表层面做的较多一些

实现方案

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

数据分库分表的方案

使用range来分

好处在于，后面扩容的时候，就会很容易，因为只要预备好，给每个月都准备好一个数据库就可以了，到了一个新的月份的时候，自然而然就睡写入新的数据库，坏处就是，大部分的请求其实都是访问最新的数据，实际生产中如果使用range，要看场景，用户不仅仅访问最新的数据，而是均匀地访问现在的数据以及历史的数据的情况下，这种方式是可以的

hash分法

好处在于说，可以平均分配每个数据库的数据两盒请求压力，但是坏处在于说扩容起来比较麻烦，会有数据迁移的这样的一个过程

一般企业开发中，hash分法还是比较常用的，后续有很多的方法来优化hash分法的问题