分布式ID方案

本文探讨了分布式系统中保持ID唯一性的需求,分析了UUID、MySQL主键自增、雪花ID以及Redis自增等方案的优缺点。重点介绍了通过改良MySQL主键自增实现的ID生成服务,该方案能解决单点问题,支持扩容,并缓解数据库压力。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

分布式ID唯一:
整个系统ID唯一
ID是数字类型,而且是趋势递增的
ID简短,查询效率快

趋势递增:
在一段时间内,生成的ID是递增的趋势,在一段时间内生成的ID在 0 - 1000之间
一段时间之后生成的ID在1000 - 2000 之间 但是在 0 -1000 之间的时候 ID有可能 第一次是 12 第二次是10 第三次是14

UUID生成方案:
代码实现简单,本机生成,性能没有问题,ID唯一性强,数据迁移简单

  • ID 无序,不能保证趋势递增 字符串存储,查询效率慢,占用的储存空间大

    ID 本身不含有业务含义,不可读

MySQL 主键自增方案:
数字化,id递增
查询效率高
具有一定的业务可读性

  • mysql挂掉无法生存ID

  • 数据库压力大,高并发扛不住 可以使用多实例下的MySQL主键自增来完成 利用设置步长的主键自增

    在这里插入图片描述
    但是这样的方案仅仅解决了单点问题,并且步长确定,不利于扩容,数据库的压力相对来说也比较大,数据库自身的性能无法满足高并发

    雪花ID的算法依赖于机器的时钟,如果服务器的始终回拨了,会导致重复的ID生成

    Redis自增生成

    改良的Mysql主键自增:
    在这里插入图片描述
    1.注册用户,用户访问ID生成服务, 查询数据库,找到对应类型的id记录,
    max_id 为0,步长为1000
    2.生成ID服务将其返回,并将max_id设置更新+步长为1000
    3.用户服务获取到max_id 0 步长 1000
    4.用户服务用 max_id 1 max_id + 步长范围 1 - 1000范围的ID
    5.用户服务将这个区间保存到jvm中
    6.用户服务需要的时候会在这个区间中获取id
    7.如果将区间的值使用完了,再去请求生产ID服务的接口,获取到max_id是1000,就可以使用下一个步长区间

     这样就可以保证一段时间才会访问MySQL解决并发高的问题
     
     但是在多线程的环境下会存在竞争问题,多个服务同时获取ID,在获取max_id的时候会存在并发问题
     此时可以利用数据库的锁去完成同一时刻只有一个服务能够获取max_id的需求
     
     还可以有双buffer的方案,
     先获取一个区间,使用到一定额度之后判断第二个buffer区有无获取记录,没有就发起请求获取第二次区间缓存,当第一个区间用完之后先使用第二个区间
    
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值