分库分表后id生成策略

分库分表后，id就不能再采取数据库主键自增的方式了，应该要一个全局唯一ID。

自己尝试过的几种方式

1、UUID。这个是随机字符串中最火的，但是不具备自增性，而且长度也太长浪费空间，作为主键不合适

2、基于数据库获取id。

基于数据库，可以有两种这样的id生成策略。

第一种就是利用全局唯一id进行自增，然后每次取出一个，但是貌似高并发下性能不是特别强。

第二种就是批量获取，比如数据库中当前的id是10000，我们一次性获取1000个id放到缓存中或者阻塞队列里面，用的时候一个个取，取完再去数据库中批量拿取。当然存放的方式也有两种，一种是直接生成1000个id的记录，另外一种就是记录当前的最大id数，比如10000取出1000个之后，记录id为11000，这样比较节省空间。但是缺点就是万一redis服务器或者业务服务器宕机，会出现这1000个id空缺。

 

3、基于twitter的SnowFlake。算法网上很多，我就主要介绍下结构

snowflake的结构如下(每部分用-分开):

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）

一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)

snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。经测试snowflake每秒能够产生26万个ID。

 

4、根据自己的业务来生成。

可以仿照snowFlake算法，自己进行一个变换，根据时间戳，业务机器id等等进行拼接。

 

5、全局ID生成之后，其他表的id如何生成？

之前自己遇到这个问题，以为其他表也是来一个全局id生成，结果GG了。

后来自己实际操作之后发现，确实如此。举例电商系统中，分库分表之后，userid进行全局唯一id生成，他的订单id不能直接用那个算法或者自增id进行全局id生成，因为一旦要查这个用户的订单，就要到进行全局搜索，肯定不行。

这时候的解决方法就是，在id后面或者前面拼接userid的后几位，一般是四位，用于定位这个id所在的库，这样就可以直接根据id定位到数据信息