美文网首页
分布式ID生成器

分布式ID生成器

作者: 水木共美 | 来源:发表于2021-07-01 14:44 被阅读0次

    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

    image.png
    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;
        }
    
    

    相关文章

      网友评论

          本文标题:分布式ID生成器

          本文链接:https://www.haomeiwen.com/subject/jxroyltx.html