单库单表到分库分表切换方案和全局ID的生成笔记_单库 切换

单库单表到多库多表切换方案

1、停机分库分表

线上停机，此时源库没有数据的变化，将之前写好的导数的工具跑起来，将源库的数据读出来通过分库分表中间件分发到分库分表中去，导入完成之后就ok了，此时就可以修改数据源的配置以及sql之类的改变在上线。

2、不停机双写方案

在线上系统里面，把所有增删改相关的操作，除了对老库增删改意外，对分库分表也同步执行增删改操作，同时写两库，系统部署玩以后使用之前的倒数工具，把旧数据读入到分库分表中，同时需要用最后更新时间作为条件，不可以旧数据覆盖新数据，导一轮之后，对新旧数据作对比，如果存在不同的数据，就在执行第二轮，直到所有数据都相等了，再重新部署。

全局ID生成方案

1、数据库自增ID

实现是当用户插入的时候，先往一个数据库一张表插入一条没有意义的数据，此时会生成一个自增ID，拿到这个ID后在作为主键放入分库分表数据库写入。这个方案的优点就是简单，但是单库生成自增ID是瓶颈。只是用低并发但数据库数据量很大需要分库分表的情况下。

2、uuid

基于UUID生成，UUID.randomUUID().toString().replace(“-”, “”) ，不适合做主键，因为UUID生成的太长了，影响SQL性能，只能用于比如零时文件名之类的。

3、基于时间戳

就是获取当前时间，但是在高并发情况下，存在相等的情况，所以不适合高并发，一半是将这个字段同其他字段拼接起来代表业务含义才使用。

4、snowflake算法

1. 使用snowflake开源算法，是将一个64位的二进制ID转化为十进制，格式：0 | 0001100 10100010 10111110
   10001001 01011100 00 | 10001 | 1 1001 | 0000
   00000000。第一位代表符号位，因为ID不为负，所以第一位默认是0，紧接着41位代表了时间戳，单位是毫秒，接下来10位代表机器id，其中前5位可以表示机房，后5位表示机器号，后面12位代表了同1毫秒内产生不同的ID。
2. 假设在2020-09-0922:30:00这一时刻，机房24机器25发送来一个请求需要生成一个id，那么snowflake算法服务会获取到信息后，先判断这个时刻这个地方的这个机器有没有在这一毫秒内已经生成过一次ID，如果有就把值+1。