本文主要是介绍分享大厂分布式唯一ID设计方案，快来围观，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
点击上方 好好学java ，选择 星标 公众号
重磅资讯、干货，第一时间送达
今日推荐：终于放弃了单调的swagger-ui了，选择了这款神器—knife4j个人原创+1博客：点击前往，查看更多
作者：老顾聊技术
www.toutiao.com/i6682672464708764174
前言
上一篇文章中介绍了分布式唯一ID你想了解一线大厂的分布式唯一ID生成方案吗？ 留了一个悬念，这里老顾就介绍一下两种大厂的方案思路。希望能够帮到大家。
改造数据库主键自增
老顾在前一篇文章中介绍了利用数据库的自增主键的特性，可以实现分布式ID；这个ID比较简短明了，适合做userId，正好符合如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)文章中的ID的需求。但这个方案有严重的问题：
1、一旦步长定下来，不容易扩容
2、数据库压力山大
我们小伙伴们看看怎么优化这个方案，先看数据库压力大，为什么压力大？是因为我们每次获取ID的时候，都要去数据库请求一次。那我们可以不可以不要每次去取？
附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南，这是本人这几年及春招的总结，目前，已经拿到了大厂offer，拿去不谢！
下载方式
1. 首先扫描下方二维码
2. 后台回复「Java面试」即可获取
思路我们可以请求数据库得到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还能维持一段时间。
竞争问题
以上方案中，如果是多个用户服务，同时获取ID，同时去请求【ID服务】，在获取max_id的时候会存在并发问题。
如用户服务A，取到的max_id=1000 ;用户服务B取到的也是max_id=1000，那就出现了问题，Id重复了。那怎么解决？
其实方案很多，加分布式锁，保证同一时刻只有一个用户服务获取max_id。当然也可以用数据库自身的锁去解决。
利用事务方式加行锁，上面的语句，在没有执行完之前，是不允许第二个用户服务请求过来的，第二个请求只能阻塞。
突发阻塞问题
上图中，多个用户服务获取到了各自的ID区间，在高并发场景下，id用的很快，如果3个用户服务在某一时刻都用完了，同时去请求【ID服务】。因为上面提到的竞争问题，所有只有一个用户服务去操作数据库，其他二个会被阻塞。
小伙伴就会问，有这么巧吗？同时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用完了，会自动切换到buffer2
5、buffer2用到10%了，也会启动线程再次获取，设置到buffer1中
6、依次往返
双buffer的方案，小伙伴们有没有感觉很酷，这样就达到了业务场景用的ID，都是在jvm内存中获得的，从此不需要到数据库中获取了。允许数据库宕机时间更长了。
因为会有一个线程，会观察什么时候去自动获取。两个buffer之间自行切换使用。就解决了突发阻塞的问题。
总结
此方案是美团公司使用的分布式ID算法，小伙伴们如果想了解更深，可以去网上搜下，老顾这里应该介绍了比较详细了。
当然此方案美团还做了一些别的优化，监控id使用频率，自动设置步长step，从而达到对id节省使用。
此ID方案非常适合老顾前几篇文章中的id需求如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇) 。
但此ID存在一定的问题，就是太过连续，竞争对手可以预测，不适合订单ID。那还有没有别的方案。下次老顾介绍一下美团的另一种生成ID方案。谢谢！！！
最后，再附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南，这是本人这几年及春招的总结，目前，已经拿到了大厂offer，拿去不谢！
下载方式
1. 首先扫描下方二维码
2. 后台回复「Java面试」即可获取
这篇关于分享大厂分布式唯一ID设计方案，快来围观的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
