分布式ID生成方案小结

Tecode 发布于2022-06-28 18:59 / 1923人阅读

摘要：几乎所有的系统都存在生成唯一的需求，如用户账单等，由于系统通常是分布式架构，因而需要有合适的分布式生成方案。优势和数据库自增方案类似缺点同样仍然有性能上限，依赖数据库的可用性。使用时，可以使用具体的场景选择合适的方案。

几乎所有的系统都存在生成唯一ID的需求，如用户ID、账单ID等，由于系统通常是分布式架构，因而需要有合适的分布式ID生成方案。

常见的分布式唯一ID方法有（欢迎补充）：

时间戳
数据库自增ID
UUID
放号系统
类snowflake

一、时间戳
原理：使用直接使用时间戳毫秒值或微秒值作为ID

缺点：每个时间单位只能生成一个ID，在分布式架构中不好保证唯一性。

适用场景：一般很少适用这种方案

二、数据库自增ID
原理：基于MySQL等数据库的auto_inscrement功能

优势：实现简单（数据库自带功能），生成的ID单调递增，保证全局唯一；ID长度灵活

缺点：存储性能上限（MySQL性能），对数据库重度依赖，一旦数据库宕机则无法生产继续生成ID。

三、UUID
原理：多个版本，大致原理是时间戳+机器ID+CPU时钟+随机数。通过CPU时钟保证本地唯一，通过机器ID+CPU时钟保证全局唯一

优势：全局唯一，本地生成，没有性能上限

缺点：生成ID过长（32位16进制字符），不是单调递增

四、放号系统
原理：通常是基于数据库自增ID的方案改造，只是每次批量获取一个号段，提升了性能。

优势：和”数据库自增ID“方案类似

缺点：同样仍然有性能上限，依赖数据库的可用性。数据库主备切换时可能发生ID冲突。存储耗时尖刺（更新DB时延时高）。因为号段通常是定长，拓展性差，对流量波动大的场景不太适用。

参考： https://tech.meituan.com/2019/03/07/open-source-project-leaf.html

升级
放号系统可以升级多个变种，比如采用多个数据库（通过数据库实例ID+数据库自增ID），在ID消耗完之前（比如消耗了50%）就预申请号段等方案。

五、类snowflake算法方案
原理：时间戳+机器ID+序列号

优势： uint64型，全局唯一，单调递增，本地生成性能高，每秒能生成的ID较多。

缺点：需要解决三大问题（增加了复杂度）

三大问题
时间回拨
时间回拨问题的几种解决方案：

直接抛异常（体验不太好）
采用历史时间（需要维护历史时间，重启时异常？）
多时间线（如果多次回拨仍然不能继续放号）

机器ID的分配和回收
机器ID的分配：

手动配置
取IP地址的hash值（比较适用于IP地址hash值不冲突的场景）
引入其他系统维护机器ID

机器ID的上限
snowflake算法使用10bit存储机器，所以机器ID的上线是2^10=1024；不过这一般也能满足业务需要了（只要做好分配和回收）

六、小结
实际业务中，<放号系统>和<类snowflake>两种方案适用的场景较广。使用时，可以使用具体的场景选择合适的方案。同时，可以结合需要进行优化。

比如：用户ID可以使用<放号系统>生成，订单号等可以使用类snowflake方案来生成。

使用类snowflake方案时，使用哪种方式分配机器ID也可以根据具体的场景选择。比如机器较少，各个进程配置方便手动配置时，可以采用手动配置的方式；如果实在集群中，Pods节点的最后8bit肯定不同，Pods自动扩缩容的场景，可以采用IP地址Hash值的方式来生成机器ID。

云服务器混合云分布式id生成器全局id生成生成全局唯一id 生成唯一id算法

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/125952.html

21世纪了还愚公移山？数据库这么迁移更稳定！

摘要：数据迁移，主要利用阿里云数据传输服务的数据迁移能力，涉及到全量迁移增量迁移一致性校验及反向任务。小结通过周密的迁移方案设计，以及强大的数据迁移工具的能力，闲鱼商品库顺利完成亿在线数据库服务迁移，独立的物理部署显著提升商品库在线服务的稳定性。背景在系统的快速迭代过程中，业务系统往往部署在同一个物理库，没有做核心数据和非核心数据的物理隔离。随着数据量的扩大这种情况会带来稳定性的风险，如...

ymyang 2019-06-25 19:08 评论0 收藏0
webpack 构建性能优化策略小结

摘要：但是，随者工程开发的复杂程度和代码规模不断地增加，暴露出来的各种性能问题也愈发明显，极大的影响着开发过程中的体验。对应的资源也可以直接由页面外链载入，有效地减小了资源包的体积。背景如今前端工程化的概念早已经深入人心，选择一款合适的编译和资源管理工具已经成为了所有前端工程中的标配，而在诸多的构建工具中，webpack以其丰富的功能和灵活的配置而深受业内吹捧，逐步取代了grunt和gu...

hiYoHoo 2019-08-21 11:21 评论0 收藏0
Webpack 3一些代码体积优化方案的小结

摘要：表示生成一个懒加载的，只有当需要时才会被加载。主要是作用域提升，将所有模块放在同一个作用域当中，一方面能提高运行速度，另一方面也能降低文件体积。前提是你的代码是用模块写的。参考文章学习小结前言之前接手公司一个前端项目，开发了几个月后越来越难以忍受项目结构的混乱和打包体积的臃肿（脚手架和基本功能代码都是从公司的其他项目复制过来的），如果不立即进行重构，难以想象以后要怎么维护各个产品线...

taowen 2019-08-22 18:20 评论0 收藏0