ID生成器介绍及著名的五大开源ID生成器的使用UUID,snowflake

最新推荐文章于 2024-07-27 21:10:28 发布

心之所向-

最新推荐文章于 2024-07-27 21:10:28 发布

阅读量5.3k

点赞数 1

分类专栏：安全优化方案文章标签： Java ID生成 SSM

本文链接：https://blog.csdn.net/qq_42217363/article/details/102514452

版权

安全优化方案专栏收录该内容

5 篇文章 0 订阅

订阅专栏

ID在我们日常开发中使用的非常频繁，几乎只要是在开发就会天天打交道，但是你知道吗，ID学问大的很呢，怎么就大了呢，有多大呢？咳咳~~ 没开车啊，注意正常，好，接下来我们开始分析分布式ID。别被名字吓死，我还记得我刚读书那会儿，听到别人说分布式，高并发就吓死了，其实没啥难的，主要这这个词确实高大上。有兴趣同学可以去搜下，这里就不做详细说明。

----------------------------------------------------------------------------------------------------------------------------------------------------装逼从分割线开始

不管是分布式系统，还是普通系统，又或者模块系统，都有ID唯一的属性，在分布式系统下，当然了，对ID的唯一性要求是更加的严格。最常见的，我们上阿里买服务器，下订单，京东买充气？？？啥啥的，咳咳，对吧。都会给你一个订单ID，或者发物流时候，有个物流单号，也是ID，这些ID是有特点的。

特点如下：

ID全局唯一，不会重复
ID的增长支持分布式使用
ID要直观显示出什么时间创建的订单
ID无重复
ID不可透露出业务信息，例如每天订单的数量

最最最重要的是保证ID的唯一性，不然两个用户下单，ID一样的，举个栗子，你买的充气？？到了别人的手里，你肯定会很难受吧。哈哈哈。咳咳，正紧点。在接着说

一般的项目都是单机数据库，在分布式系统中当然是数据库集群，分库分表较为多，当我们的数据库达到一定规模的时候，就需要对其进行分库分表，分库分表的时候我们就很难保证主键ID的唯一性，这一点很好理解。这是因为，我们的一张表被分割到不同机器上的数据库中，如果还依靠与数据库自带的自增功能的话就很那保证ID唯一性！如图：

可以看出，User表中的100W数据被分到两个数据库中，在每一个数据库内部主键ID是自增的，但是却没法保证全局主键ID自增的，这显然是错误的！如何解决这种问题哪？那么强大的ID生成器介绍开始了，各位千万不要眨眼，因为这东西你们出去我保证你们百分之一万都会用到。

一、UUID(java.util.UUID包中)

UUID (Universally Unique Identifier) 的标准型式包含 32 个 16 进制数字，以连字号分为五段，形式为 8-4-4-4-12 的 36 个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有 5 种方式生成 UUID。

UUID 的优点：性能非常高：本地生成，没有网络消耗。

UUID 的缺点：

不易于存储：UUID 太长，16 字节 128 位，通常以 36 长度的字符串表示，很多场景不适用。
信息不安全：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
ID 作为主键时在特定的环境会存在一些问题，比如做 DB 主键的场景下，UUID 就非常不适用。MySQL 官方有明确的建议主键要尽量越短越好，36 个字符长度的 UUID 不符合要求；UUID 还对 MySQL 索引不利，如果作为数据库主键，在 InnoDB 引擎下，UUID 的无序性可能会引起数据位置频繁变动，严重影响性能。

二、snowflake（Twitter公司的著名的《雪花算法》）

优点：

毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
可以根据自身业务特性分配bit位，非常灵活。

缺点：

强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。

MongDB 的 ObjectID 可以算作是和snowflake类似方法，通过“时间+机器码+pid+inc”共12个字节，通过4+3+2+3的方式最终标识成一个24长度的十六进制字符。

三、Leaf(美团开源)

支持多种不同模式的生成策略

号段模式：该模式需要建 DB 表, 需要有专门的服务来提供获取 id 的接口, 存在网络延迟

Snowflake 模式：为了追求更高的性能，需要通过 RPC Server 来部署 Leaf 服务，那仅需要引入 leaf-core 的包，把生成 ID 的 API 封装到指定的 RPC 框架中即可

缺点，可能就是相对来说比较复杂。

四、uid-generator（百度开源）

uid-generator 是百度开源的一个分布式 ID 生成器。需要建 DB 表, 需要有专门的服务来提供获取 id 的接口, 存在网络延迟。

五、Vesta框架

Vesta是一款通用的ID产生器，互联网俗称统一发号器，它具有全局唯一、粗略有序、可反解和可制造等特性，它支持三种发布模式：嵌入发布模式、中心服务器发布模式、REST发布模式，根据业务的性能需求，它可以产生最大峰值型和最小粒度型两种类型的ID，它的实现架构使其具有高性能，高可用和可伸缩等互联网产品需要的质量属性，是一款通用的高性能的发号器产品。

-----------------------------------------------------------------------------------没源码万人骂。

接下来上源码:

一、UUID和snowflake