【数据库】——分库分表（2）

一、动态扩容

前面我们已经说了分库分表的一些概念，那么现在问题来，假如我们现在分库分表了，4个库，4张表，就是原先的单台的一张表现在拆分成4个库中的实际16张表，可是加入我们是一段时间之后又需要扩容怎么办？

最好方案就是一次到位，32个库和32个表，总共是1024个表，加入一个表的数据量是500万，那么就是50亿数据，可以用几年了，对于中小型互联网来说，每个库的并发量1000，那就可以支持32000的并发量，刚开始的时候，这个库可能就是逻辑库，建在一个数据库上的，就是一个 mysql 服务器可能建了 n 个库，比如 32 个库，后期可以扩展到32个数据库服务器，最多是1024台，后期就是不断在库和 mysql 服务器之间做迁移就可以了。

二、分布式id

数据库自增 id：对于并发量不高（几百或者更低）可以适用，走单独的库和表生成主键

设置数据库 sequence 或者表自增字段步长：能达到目标，但是服务节点固定，步长也固定，将来增加服务节点不好弄

UUID：简单、本地生成，但是作为主键效率低下（不具有有序性，导致B+树在写入的时候有过多的随机写操作）

获取系统当前时间：对于高并发不使用，除非增加业务字段拼接

snowflake 算法：snowflake 算法是 twitter 开源的分布式 id 生成算法，采用 Scala 语言实现，是把一个 64 位的 long 型的 id，1 个 bit 是不用的，用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 id，12 bit 作为序列号。适用于高并发场景生成分布式ID。

三、迁移方案

停机迁移方案：通告停机时间段，开始数据导入新库并验证，最后重启服务

双写迁移方案：之前对老库的增删改对新库也执行，也就是同时写两库，系统部署之后，将老库的数据导入到新库，但是注意不要将老库的老数据覆盖了新库的新数据，一轮之后开始check新老数据库的数据一致性，不一致的重新写入，直到一致。