分库分表-以及相关问题

普通服务器，数据库保持2000并发以下。

走数据库中间件，分发到各个数据库里面去。

也两种：
1 代理类型, 独立部署出来，独立部署一个集群。
MyCat
优点： 不需要改造各个业务系统。
缺点：需要部署和维护Mycat集群。

2 Client。只是一个jar，和WEB系统放在一起的。
Sharding-jdbc。
优点：不需要额外部署，直接放在业务系统系统。
缺点：如果要改造或者升级，所有相关的业务系统都需要改造，都改成使用sharding-jdbc。

分表：
垂直拆分： 将一张大表切分成多张小表， 频繁访问的字段放一张表，不那么频繁的放其他的表。

水平拆分：表结构都一样， 将一张有大量数据的表的数据，迁移拆分到多个数据库服务器。
或者，一个数据库里面，将一张表结构复制多份，例如用户表 User， 分为 User1， User2， User3，3张表，结构一样， 里面存的数据不一样。

按照ID来拆分一般叫做 Hash
扩容比较麻烦，可能会需要造成数据迁移。 但是流量可以较为均匀的分发到各个数据库里面去。

按照时间或者某个维度来拆分，叫做range拆分
扩容简单，可能会造成流量分发不均衡，容易造成流量集中访问到某些库里面去。

带来的问题：

跨库分页：
join： 分多次查询，在代码逻辑层面解决。
增加代码的复杂度，而且有些分页或者某些功能无完成。

count：

order by：
group by：
事务:
采用分布式事务。

迁移分库分表

停机迁移
简单停机，迁移数据，然后切换数据源完事。

不停机迁移
双写迁移
修改业务系统， 同事向旧库写入和向新库写入。

需要进行历史数据迁移， 需要自行开发程序来进行迁移。
迁移历史数据后， 还需要检查旧库和新库是否一致；如果不一致，则一直做迁移和检查，直到一致为止。

最后修改系统， 将双写改为单写。

扩容缩容

单台服务器并发撑不住就扩容。单表太大就扩容。

停机扩容
建立好新的库，编写迁移程序，然后找个业务低峰期，然后停机。 运行迁移程序，将旧的数据，迁移到新的数据库系统。 然后进行校验， 完成后释放掉旧的数据库服务器。

极度不推荐的方案。效率低。

动态扩容
第一次进行分库分表带时候， 就一次分配够， 对数据容量和并发承载都有一个扩大的预估。

一台服务器，部署32个库， 每个库32张表。
扩展的时候，2台服务器，每台16个库，每个库32张表。
最终可以扩展到32台服务器， 每台服务器1个库， 每个库32张表。
缩容也是如此。

只需要修改，数据库的连接字符串，容易扩展。

全局ID

方案1：
部署一个生成主键的库，用于生成自增id。
优点：简单，容易。
缺点：主键库可能成为瓶颈。

方案2：
UUID：
本地代码生成
优点：简单，便捷。
缺点：太长，不是自增，降低插入效率，对聚簇索引造成调整的压力。

方案3:
可以使用当前时间戳+自定义的业务模块id+随机数。
优点：本地生成，比较快， 由于时间戳有一定的顺序，插入的索引调整不会太大。
缺点：获取当前时间戳不一定很高效率。

方案4：
雪花算法