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

比眉伴天荒 2022-04-24 11:10 228阅读 0赞

老顾聊技术 2019-04-23 11:34:07

**欢迎关注头条号：老顾聊技术**

**精品原创技术分享，知识的组装工**

--------------------

# 目录 #

1.  前言
2.  改造数据库主键自增
3.  竞争问题
4.  突发阻塞问题
5.  双buffer方案
6.  总结

# 前言 #

上一篇文章中介绍了分布式唯一ID[你想了解一线大厂的分布式唯一ID生成方案吗？][ID] ，留了一个悬念，这里老顾就介绍一下两种大厂的方案思路。希望能够帮到大家。

# 改造数据库主键自增 #

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

> **1、一旦步长定下来，不容易扩容**
> 
> **2、数据库压力山大**

我们小伙伴们看看怎么优化这个方案，**先看数据库压力大，为什么压力大？**是因为我们每次获取ID的时候，**都要去数据库请求一次**。那我们**可以不可以不要每次去取**？

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

![分享大厂分布式唯一ID设计方案，快来围观][ID 1]

我们看上图，有张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 2]

利用**事务方式加行锁**，上面的语句，在没有执行完之前，是不允许第二个用户服务请求过来的，第二个请求只能阻塞。

# 突发阻塞问题 #

![分享大厂分布式唯一ID设计方案，快来围观][ID 3]

上图中，**多个用户服务获取到了各自的ID区间**，在高并发场景下，id用的很快，如果3个用户服务在**某一时刻都用完**了，**同时去请求【ID服务】**。因为上面提到的竞争问题，所有只有一个用户服务去操作数据库，**其他二个会被阻塞**。

> 小伙伴就会问，有这么巧吗？同时id用完。我们这里举的是3个用户服务，感觉概率不大；**如果是100个用户服务呢？概率是不是一下子大了**。

出现的现象就是**一会儿突然系统耗时变长，一会儿好了**，就是这个原因导致的，怎么去解决？

# 双buffer方案 #

在一般的系统设计中，双buffer会经常看到，怎么去解决上面的问题也可以采用双buffer方案。

![分享大厂分布式唯一ID设计方案，快来围观][ID 4]

在设计的时候，**采用双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需求[如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)][Link 1] 。

但此**ID存在一定的问题，就是太过连续，竞争对手可以预测，不适合订单ID**。那还有没有别的方案。下次老顾介绍一下美团的另一种生成ID方案。谢谢！！！

--------------------

**-End-**

**如有收获，请帮忙转发，您的鼓励是作者最大的动力，谢谢！**

**10几年的经验实战分享**

**相关微服务，分布式，高并发，高可用，企业实战，干货等原创文章正在路上**

**欢迎关注头条号：老顾聊技术**

**精品原创技术分享，知识的组装工**

> **推荐阅读**
> 
> 1、[你想了解一线大厂的分布式唯一ID生成方案吗？][ID]
> 
> 2、[如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)][Link 1]
> 
> 3、[你知道怎么分库分表吗？如何做到永不迁移数据和避免热点吗？][Link 2]
> 
> 4、[你了解大型网站的页面静态化吗？][Link 3]
> 
> 5、[你知道如何更新缓存吗？如何保证缓存和数据库双写一致性？][Link 4]
> 
> 6、[你知道怎么解决DB读写分离，导致数据不一致问题吗？][DB]
> 
> 7、[DB读写分离情况下，如何解决缓存和数据库不一致性问题？][DB 1]
> 
> 8、[你真的知道怎么使用缓存吗？][Link 5]
> 
> 9、[如何利用锁，防止缓存击穿？重构思想的重要性][Link 6]
> 
> 10、[海量订单产生的业务高峰期，如何避免消息的重复消费？][Link 7]
> 
> 11、[你知道如何保障生产端100%消息投递成功吗？][100]

[ID]: https://www.toutiao.com/i6682195317716156942/?group_id=6682195317716156942
[Link 1]: https://www.toutiao.com/i6678174710284419588/?group_id=6678174710284419588
[ID 1]: http://p1.pstatp.com/large/pgc-image/c6917304c7b5451baeb5cf33dd17264a
[ID 2]: http://p1.pstatp.com/large/pgc-image/e1ce1c30818749febaff462ec4b6e3e9
[ID 3]: http://p9.pstatp.com/large/pgc-image/c5072c69e6de4cf4976c3772cbe59e37
[ID 4]: http://p1.pstatp.com/large/pgc-image/97927e81a21c469c927e39c07f84de55
[Link 2]: https://www.toutiao.com/i6677459303055491597/?group_id=6677459303055491597
[Link 3]: https://www.toutiao.com/i6671093883025228301/?group_id=6671093883025228301
[Link 4]: https://www.toutiao.com/i6669945231242166791/?group_id=6669945231242166791
[DB]: https://www.toutiao.com/i6670699080143864327/?group_id=6670699080143864327
[DB 1]: https://www.toutiao.com/i6670734129279009288/?group_id=6670734129279009288
[Link 5]: https://www.toutiao.com/i6667340156875309572/?group_id=6667340156875309572
[Link 6]: https://www.toutiao.com/i6668092476537963022/?group_id=6668092476537963022
[Link 7]: https://www.toutiao.com/i6666219332915167756/?group_id=6666219332915167756
[100]: https://www.toutiao.com/i6672235084336071179/?group_id=6672235084336071179