一线大厂的分布式 ID 生成方案是什么样的?

1 前言

分布式系统中我们会对遇到数据量较大的业务表进行拆分,如:订单表、用户表,但是有时又需要保证id需要在整个系统保证唯一,这个时候就需要使用到分布式id。

2 分布式id需要满足什么条件才是符合要求的

分布式id生成方案需要保证满足一下条件才算是合理的方案

  • 整个系统唯一
  • id是数字类型,并且在一定范围是趋于增长趋势
  • id简短,查询效率快
3 分布式id的几种方案
3.1 UUID

优点:

  • 代码简单
  • 本机生成,没有性能问题,不需要引入任何中间件
  • 全球问一,迁移数据容易

缺点:

  • 每次UUID都是无序的,无法保证趋势递增
  • UUID的字符存储太长,查询效率慢
  • ID无业务含义,不可读

应用场景:

  • 类似生成token令牌的场景
  • 不适合一些要求有趋势递增的ID场景
3.2 数据库自增主键

这个方案是利用了数据库自增auto_increament,默认每次都是ID加1.

优点:

  • 数字化,id递增
  • 查询效率高
  • 具有一定的业务可读

缺点:

  • 存在单点问题,如果mysql挂了,就没有生成id了
  • 数据库在高并发时存在瓶颈,读写压力比较大
3.3 数据库多实例

此方案是来解决数据库单点问题,在auto_increment基本上面,设置step步长

在这里插入图片描述

每台的初始值分别为1,2,3…N,步长为N(这个案例为3)

优点:

  • 解决了单点问题

缺点:

  • 一旦把步长定好之后,就无法扩容;并且单个数据库压力比较大,数据库自身性能无法满足

应用场景:

  • 数据不需要扩容的场景
3.4 雪花算法

雪花算法生成64位的二进制正整数,然后转换成10进制的数。64位二进制数由如下部分组成:

在这里插入图片描述

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

优点:

  • 此方案每秒能够产生409.6万个ID,性能快
  • 时间戳在高位,自增序列在低位,整个ID是趋势递增的,按照时间有序递增
  • 灵活度高,可以根据业务需求,调整bit位的划分,满足不同的需求

缺点:

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

在分布式场景中,服务器时钟回拨会经常遇到,一般存在10ms之间的回拨;小伙伴们就说这点10ms,很短可以不考虑吧。但此算法就是建立在毫秒级别的生成方案,一旦回拨,就很有可能存在重复ID。

3.5 redis生成方案

利用redis的incr原子操作性自增,一般算法为:

年份 + 当天距当年第多少天 + 天数 + 小时 + redis自增

优点:

  • 有序递增,可读性强

缺点:

  • 占用带宽,每次都要向redis进行请求

性能还行,但是在高并发情况下还需要调用redis发送网络请求(虽然redis性能很高,但是也是存在瓶颈的。)

3.6 zookeeper生成方案
3.7 小结

常见的分布式id生成方案各有优缺点,一线大厂的分布式id方案绝对不会这么简单,他们对高可用,高并发要求比较高。

类似redis方案中,每次都要去redis去请求,有网络请求耗时,并发强依赖redis。而且这个设计有风险,一旦redis挂了,整个系统不可用。

而且一线大厂也会考虑到ID安全性的问题,如:Redis方案中,用户是可以预测下一个ID号是多少,因为算法是递增的。

4 一线大厂是如何设计的?
4.1 改造数据库主键自增

利用数据库的自增主键的特性,可以实现分布式ID;这个ID比较简短明了,适合做userId,正好符合如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)文章中的ID的需求。但这个方案有严重的问题:

  • 一旦步长定下来,不容易扩容
  • 数据库压力山大

数据库压力大,为什么压力大?是因为每次获取id的时候,都要去数据库请求一次。要避免每次都去数据库获取。

思路我们可以请求数据库得到ID的时候,可设计成获得的ID是一个ID区间段。

在这里插入图片描述

有张ID规则表:

  1. id表示为主键,无业务含义。
  2. biz_tag为了表示业务,因为整体系统中会有很多业务需要生成ID,这样可以共用一张表维护
  3. max_id表示现在整体系统中已经分配的最大ID
  4. desc描述
  5. update_time表示每次取的ID时间

整体流程:

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

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

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

4、【用户服务】获得max_id=0,step=1000;

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

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

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

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

这个方案就非常完美的解决了数据库自增的问题,而且可以自行定义max_id的起点,和step步长,非常方便扩容。

而且也解决了数据库压力的问题,因为在一段区间内,是在jvm内存中获取的,而不需要每次请求数据库。即使数据库宕机了,系统也不受影响,ID还能维持一段时间

4.2 竞争问题

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kJIwMrm2-1603985220294)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20201029231044207.png)]

可以通过分布式锁或者数据库自身锁方式来解决这个问题

4.3 突发阻塞问题

在这里插入图片描述

多个用户服务同时获得了各自的ID区间,高并发情况下Id用的很快。如果采用分布式锁或者数据库锁方式来控制的话,就会出现有一个操作数据库,其他二个会被阻塞。

如果采用出现的现象就是一会儿突然系统耗时变长,一会儿好了,就是这个原因导致的。

4.4 双buffer方案(美团leaf)

在一般的系统设计中,双buffer会经常看到,怎么去解决上面的问题也可以采用双buffer方案。
在这里插入图片描述

1、当前获取ID在buffer1中,每次获取ID在buffer1中获取

2、当buffer1中的Id已经达到区间的10%

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

4、如果buffer1用完了,会自动切换到buffer2

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

6、依次往返

双buffer的方案,达到了业务场景用的ID,都是在jvm内存中获得的,从此不需要到数据库中获取了。允许数据库宕机时间更长了。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值