原创 五种常见的分布式ID,三分钟速览

相信每个人在互联网的业务系统中，每天都能接触到各种各样的ID，如在支付系统中就会有支付ID、退款ID等。今天，小编就来盘点五种分布式ID。

一、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

snowflake 我就不在介绍了，我直接说它的优点：

毫秒数在高位，自增序列在低位，整个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 框架中即可.

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

四、sharding-jdbc

sharding-jdbc 是一个开源的主键生成组件。它的特点是简单易用，可以指定 workerId 或者不指定, 直接通过 jar 的方式引入即可。看它的名字就知道，它需要 DB 支持。

五、uid-generator

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

以上就是大家比较常见的五种分布式ID,大家都了解了吗？