586047289
032-19314023
导航

分享大厂漫衍式唯一ID设计方案 快来围观

发布日期:2021-07-29 20:26

本文摘要:接待关注头条号:老顾聊技术精品原创技术分享,知识的组装工目录前言革新数据库主键自增竞争问题突发阻塞问题双buffer方案总结前言上一篇文章中先容了漫衍式唯一ID你想相识一线大厂的漫衍式唯一ID生成方案吗? ,留了一个悬念,这里老顾就先容一下两种大厂的方案思路。希望能够帮到大家。

亚慱体育app官方下载

接待关注头条号:老顾聊技术精品原创技术分享,知识的组装工目录前言革新数据库主键自增竞争问题突发阻塞问题双buffer方案总结前言上一篇文章中先容了漫衍式唯一ID你想相识一线大厂的漫衍式唯一ID生成方案吗? ,留了一个悬念,这里老顾就先容一下两种大厂的方案思路。希望能够帮到大家。革新数据库主键自增老顾在前一篇文章中先容了使用数据库的自增主键的特性,可以实现漫衍式ID;这个ID比力简短明晰,适合做userId,正好切合如何永不迁移数据和制止热点? 凭据服务器指标分配数据量(揭秘篇)文章中的ID的需求。

但这个方案有严重的问题:1、一旦步长定下来,不容易扩容2、数据库压力山大我们小同伴们看看怎么优化这个方案,先看数据库压力大,为什么压力大?是因为我们每次获取ID的时候,都要去数据库请求一次。那我们可以不行以不要每次去取?思路我们可以请求数据库获得ID的时候,可设计成获得的ID是一个ID区间段。我们看上图,有张id规则表:1、id表现为主键,无业务寄义。2、biz_tag为了表现业务,因为整体系统中会有许多业务需要生成ID,这样可以共用一张表维护3、max_id表现现在整体系统中已经分配的最大ID4、desc形貌5、update_time表现每次取的ID时间我们再来看看整体流程:1、【用户服务】在注册一个用户时,需要一个用户ID;会请求【生成ID服务(是独立的应用)】的接口2、【生成ID服务】会去查询数据库,找到user_tag的id,现在的max_id为0,step=10003、【生成ID服务】把max_id和step返回给【用户服务】;而且把max_id更新为max_id = max_id + step,即更新为10004、【用户服务】获得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还能维持一段时间。

竞争问题以上方案中,如果是多个用户服务,同时获取ID,同时去请求【ID服务】,在获取max_id的时候会存在并发问题。如用户服务A,取到的max_id=1000 ;用户服务B取到的也是max_id=1000,那就泛起了问题,Id重复了。那怎么解决?其实方案许多,加漫衍式锁,保证同一时刻只有一个用户服务获取max_id。固然也可以用数据库自身的锁去解决。

使用事务方式加行锁,上面的语句,在没有执行完之前,是不允许第二个用户服务请求过来的,第二个请求只能阻塞。突发阻塞问题 上图中,多个用户服务获取到了各自的ID区间,在高并发场景下,id用的很快,如果3个用户服务在某一时刻都用完了,同时去请求【ID服务】。因为上面提到的竞争问题,所有只有一个用户服务去操作数据库,其他二个会被阻塞。

亚慱体育app在线下载

小同伴就会问,有这么巧吗?同时id用完。我们这里举的是3个用户服务,感受概率不大;如果是100个用户服务呢?概率是不是一下子大了。

泛起的现象就是一会儿突然系统耗时变长,一会儿好了,就是这个原因导致的,怎么去解决?双buffer方案在一般的系统设计中,双buffer会经常看到,怎么去解决上面的问题也可以接纳双buffer方案。在设计的时候,接纳双buffer方案,上图的流程:1、当前获取ID在buffer1中,每次获取ID在buffer1中获取2、当buffer1中的Id已经使用到了100,也就是到达区间的10%3、到达了10%,先判断buffer2中有没有去获取过,如果没有就立刻提倡请求获取ID线程,此线程把获取到的ID,设置到buffer2中。4、如果buffer1用完了,会自动切换到buffer25、buffer2用到10%了,也会启动线程再次获取,设置到buffer1中6、依次往返双buffer的方案,小同伴们有没有感受很酷,这样就到达了业务场景用的ID,都是在jvm内存中获得的,今后不需要到数据库中获取了。允许数据库宕机时间更长了。

因为会有一个线程,会视察什么时候去自动获取。两个buffer之间自行切换使用。就解决了突发阻塞的问题。

总结此方案是美团公司使用的漫衍式ID算法,小同伴们如果想相识更深,可以去网上搜下,老顾这里应该先容了比力详细了。固然此方案美团还做了一些此外优化,监控id使用频率,自动设置步长step,从而到达对id节约使用。此ID方案很是适合老顾前几篇文章中的id需求如何永不迁移数据和制止热点? 凭据服务器指标分配数据量(揭秘篇)。

但此ID存在一定的问题,就是太过一连,竞争对手可以预测,不适合订单ID。那另有没有此外方案。

下次老顾先容一下美团的另一种生成ID方案。谢谢!!!-End-如有收获,请帮助转发,您的勉励是作者最大的动力,谢谢!10几年的履历实战分享相关微服。


本文关键词:分享,大厂,漫衍,式,唯一,设计,方案,快来,围观,亚慱体育app在线下载

本文来源:亚慱体育app在线下载-www.mxbgjj.com