分库分表

为什么要分库分表？

单表并发高，数据量大，无法承载
分库：将一个库的数据拆分到多个相同的库中，访问的时候访问一个库
分表：把一个表的数据放到多个表中，操作对应的某个表就行

如何对数据库进行垂直拆分和水平拆分

• 垂直拆分
  把一个有很多字段的表拆分成多个表，或者是多个库上去。每个库表的结构不一样，每个库表包含部分字段。一般来说，将较少的访问频率很高的字段放到一个表中，然后较多访问频率低的字段放到另一个表中
  对一些字段特别多的表做一下拆分
• 水平拆分
  把一个表的数据弄到多个库的多个表里去，但是每个库的结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。
  意义：将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容
  并发承载不了，或者是数据量太大，容量承载不了，于是进行拆分

• 分库分表其他方式
  • 按range来分
    每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了
    优点：扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了 缺点：大部分的请求，都是访问最新的数据。实际生产用range，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据
  • hash分法
    优点：可以平均分配每个库的数据量和请求压力 缺点：扩容起来比较麻烦，会有一个数据迁移的这么一个过程

如何不停机迁移分库分表

不停机双写迁移
在线上系统里面，之前所有写库的地方，增删改操作，都除了对老库增删改，都加上对新库的增删改，这就是所谓双写，同时写俩库，老库和新库
系统部署之后，新库数据差太远，用之前说的导数工具，跑起来读老库数据写新库，写的时候要根据gmt_modified这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写
接着导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止
接着当数据完全一致了，就ok了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么，还没有几个小时的停机时间，很稳。所以现在基本玩儿数据迁移之类的，都是这么干了

有哪些分库分表中间件

• cobar
  阿里b2b团队开源，proxy层，现在没啥人用，不支持读写分离，存储过程、跨库join和分页等操作
• TDDL
  淘宝团队开发，client层，不支持join、多表查询等语法，目前用的不多，而且还依赖淘宝的diamond配置管理系统
• atlas
  360开源，proxy层，社区最新的维护在5年前，目前没什么人用
• sharding-jdbc
  当当开源，client层，SQL语法支持多，支持分库分表、读写分离、分布式id生成、柔性事务，社区活跃，目前还在更新维护，可选
  优点：无需部署，运维成本低，API直接调用，性能高 缺点：如果版本更新，各个系统都需要进行升级
• mycat
  基于cobar改造，proxy层，支持的功能非常完善，目前非常火的，而且不断流行的数据库中间件，社区很活跃，相比sharding-jdbc年轻，缺少锤炼，可选
  优点：对于各个项目透明，如需升级，只需更新mycat本身，无需更新其他系统 缺点：需要部署，自己运维一套中间件，成本高

如何动态的扩容缩容分库分表

1、设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是32库 * 32表，对于大部分公司来说，可能几年都够了
2、路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表
3、扩容的时候，申请增加更多的数据库服务器，装好mysql，倍数扩容，4台服务器，扩到8台服务器，16台服务器
4、由dba负责将原先数据库服务器的库，迁移到新的数据库服务器上去，很多工具，库迁移，比较便捷
5、我们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址
6、重新发布系统，上线，原先的路由规则变都不用变，直接可以基于2倍的数据库服务器的资源，继续进行线上系统的提供服务

分库分表的主键唯一ID如何生成

• 数据库自增ID
  维护一个库中的一张表用来获取自增ID，用于其他分库分表的数据
  优点：方便简单 缺点：单库单表，并发高有性能瓶颈
  适合场景：对于并发不高的情况下，可以走单独的库和表生成自增主键ID
• UUID
  优点：基于本地生成 缺点：长度太长，做主键性能差
  适合场景：如果你是要随机生成个什么文件名了，编号之类的，你可以用uuid，但是作为主键是不能用uuid的
  获取当前系统时间
  缺点：并发很高的时候，比如一秒并发几千，会有重复的情况，这个是肯定不合适的
  适合场景：将当前时间跟很多其他的业务字段拼接起来，作为一个id，如果业务上你觉得可以接受，那么也是可以的。 你可以将别的业务字段值跟当前时间拼接起来，组成一个全局唯一的编号，订单编号，时间戳 + 用户id + 业务含义编码
• snowflake算法
  twitter开源的分布式id生成算法，就是把一个64位的long型的id，1个bit是不用的，用其中的41 bit作为毫秒数，用10 bit作为工作机器id，12 bit作为序列号
  优点：性能好，支持高并发