1、ID生成的要求
- 全局唯一性： 不重复
- 趋势递增： 多数的RDBMS数据库使用B-Tree来存储索引结构，主键有序有利于插入效率 避免缓存失效，页裂变等
- 单调递增：保证下一个ID一定大余上一个ID，满足如事务版本号，消息顺序等需求
- 信息安全：避免通过ID泄露太多信息 如找一天的开头和结尾的Id号差，可以获取一个系统一天的订单量
2、UUID
36位 8-4-4-4-12 去掉- 32位 byte
优点：
性能高，
无需网络
缺点：
无序，
太长，
包含mac地址信息不安全，
作为DB主键不合适 - a、主键长度推荐短点 b、uuid无序性，数据位置频繁变动，影响性能
3、类雪花算法 snowflake
64位 bit
1位 不用
41位 时间戳
10位 workID
12位 序列递增
可根据实际情况调整 各个部分占位数
优点：
1、趋势递增 时间位在高位
2、不依赖第三方系统
3、可根据需求分配bit位
缺点：
1、时钟回拨的情况下，可能出现重复id --- 可以等待一段时间，时钟跟上次正向后再发号
2、机器id的分配方案，机器宕机后，机器id回收的问题 --- 使用zk做id分配
3、机器id存在上限 10bit 1024 ---
算法应用：如MongoDB的ObjectId自生成
时间+机器码+pid+inc 4+3+2+3 共12个byte 最终标识为24ge16进制字符
1byte -> 8bit 16进制 -> 4bit 所以1byte可以标识为2个16进制字符
571094e2976aeb1df982ad4e
57 -> 01010111
4、数据库生成
如mysql 利用 auto_increment_increment auto_increment_offset
sql replace into 如果已存在数据，则删除后插入 如果不存在数据直接插入
begin;
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;
事务保证 插入的和查询到的是同一条ID记录
不用insert 是保证数据库不会无限增长
不用delete 是减少一次查询，减少交互
优点：
1、单调递增
2、直接使用数据库自带实现，简单
缺点：
1、强依赖DB，DB宕机不可用 - 如果使用主从机解决高可用问题，又会出现主从切换时的重复发号问题
2、性能瓶颈依赖单mysql数据库的性能
可以分库分表横向扩容，解决单mysql的性能问题，如步长相同，每台msyql都用不同的初始值，可以做到不重复发号
问题：
ID没法单调递增了，只能趋势递增
每次生成号都得读写一次数据库，压力还是在数据库上
定好步长和初始值后，后期再扩容困难
5、Leaf数据库方案
表增加业务字段 biz_tag 用来做不同业务区分 - 方便后续分库分表基于业务字段进行拆分
表字段step max_id 自己存储当前发号最大id号和步长，不依赖数据库自己的auto_increment特性
这时的step步长标识一次取号的批量数据，等这批数据用完后再来取数，减轻了mysql的交互压力
begin
update table set max_id=max_id+step where biz_tag=xxx;
select biz_tag, max_id, step where biz_tag=xxx;
commit
优点：
方便横向扩展
ID是long型64位递增数字，满足主键要求
客户端有号段缓存 max_id-step 到max_id，取完才去数据库取 能一定程度缓解可用性
max_id可自定义，方便其他业务迁移
缺点：
递增数据容易泄露发号规律
当号段用完后，去数据库取数时，还是可能会引起高并发，阻塞
DB宕机会不可用
优化方案：
1、双buffer 号段还没用完时，就去提前取下一个号段，可以不需要等待取号阻塞 2个segment
segment设置为10分钟的高峰用号量， 这样DB宕机也有10-20分钟
不会阻塞在segment取号
2、DB可用性 使用一主两从，分机房部署，半同步方式同步数据 主从切换需要中间件
6、Leaf雪花算法方案
还是1+41+10+12 分配方案
1、利用zk的持久顺序节点 来生成workid ，重启后直接获取是否已经分配过id
2、弱依赖zk，每次的workid获取后都会在本地存储
3、周期性上传本机时间到zk上，每次取号都要检查当前时间是否出现了回拨，出现则失败，告警
4、检查本机时间和zk上的平均时间是否偏移过大，出现则失败告警
7、我们的实现
redis 单线程原子性 实现一个业务字段的递增
private long getUniqueAtomicLong(String tag) {
RAtomicLong atomicLong = redissonClient.getAtomicLong(tag);
boolean flag = atomicLong.compareAndSet(Long.MAX_VALUE, 0);
if(flag) {
return Long.MAX_VALUE;
}
long lo = atomicLong.getAndIncrement();
return lo;
}
