分布式唯一建ID

代码实现简单

本机生成，没有性能问题

因为是全球唯一的ID，所以迁移数据容易

优点

每次生成的ID是无序的，无法保证趋势递增

UUID的字符串存储，查询效率慢

存储空间大

ID本事无业务含义，不可读

缺点

类似生成token令牌的场景

不适用一些要求有趋势递增的ID场景

应用场景

UUID

数字化，id递增

查询效率高

具有一定的业务可读

存在单点问题，如果mysql挂了，就没法生成iD了

数据库压力大，高并发抗不住

MySQL主键自增

解决了单点问题

一旦把步长定好后，就无法扩容；而且单个数据库的压力大，数据库自身性能无法满足高并发

数据不需要扩容的场景

MySQL多实例主键自增

此方案每秒能够产生409.6万个ID，性能快

时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增

灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求

依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成

1位标识符：始终是041位时间戳：41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截 )得到的值，这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的10位机器标识码：可以部署在1024个节点，如果机器分机房（IDC）部署，这10位可以由 5位机房ID + 5位机器ID 组成12位序列：毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号

雪花snowflake算法

有序递增，可读性强

占用带宽，每次要向redis进行请求

一旦Redis挂了，整个系统不可用。

Redis方案中，用户是可以预测下一个ID号是多少，因为算法是递增的。

利用redis的incr原子性操作自增，一般算法为：年份 + 当天距当年第多少天 + 天数 + 小时 + redis自增

实现

Redis生成方案

生成方案

id表示为主键，无业务含义

biz_tag为了表示业务，因为整体系统中会有很多业务需要生成ID，这样可以共用一张表维护

max_id表示现在整体系统中已经分配的最大ID

desc描述

update_time表示每次取的ID时间

设计

【用户服务】在注册一个用户时，需要一个用户ID；会请求【生成ID服务(是独立的应用)】的接口

【生成ID服务】会去查询数据库，找到user_tag的id，现在的max_id为0，step=1000

【生成ID服务】把max_id和step返回给【用户服务】；并且把max_id更新为max_id = max_id + step，即更新为1000

【用户服务】获得max_id=0，step=1000；

这个用户服务可以用ID=【max_id + 1，max_id+step】区间的ID，即为【1，1000】

【用户服务】会把这个区间保存到jvm中

【用户服务】需要用到ID的时候，在区间【1，1000】中依次获取id，可采用AtomicLong中的getAndIncrement方法。

如果把区间的值用完了，再去请求【生产ID服务】接口，获取到max_id为1000，即可以用【max_id + 1，max_id+step】区间的ID，即为【1001，2000】

具体流程

如果是多个用户服务，同时获取ID，同时去请求【ID服务】，在获取max_id的时候会存在并发问题

场景

加分布式锁，保证同一时刻只有一个用户服务获取max_id

利用事务方式加行锁

解决

竞争问题

多个用户服务获取到了各自的ID区间，在高并发场景下，ID用的很快，如果3个用户服务在某一时刻都用完了，同时去请求【ID服务】。因为上面提到的竞争问题，所有只有一个用户服务去操作数据库，其他二个会被阻塞。

当前获取ID在buffer1中，每次获取ID在buffer1中获取

当buffer1中的Id已经使用到了100，也就是达到区间的10%

达到了10%，先判断buffer2中有没有去获取过，如果没有就立即发起请求获取ID线程，此线程把获取到的ID，设置到buffer2中。

如果buffer1用完了，会自动切换到buffer2

buffer2用到10%了，也会启动线程再次获取，设置到buffer1中

依次往返

具体实现

双buffer方案

突发阻塞问题

问题

此ID存在一定的问题，就是太过连续，竞争对手可以预测，不适合订单ID。

改造数据库主键自增

大厂方案

分布唯一ID生成https://www.cnblogs.com/myseries/p/12882207.html