五大分布式ID生成器优缺点及对比（Java）

首选，不管是不是分布式系统，都有 ID 唯一的使用场景。而在分布式场景下，对 ID 的唯一性要求更严格！
常见的，我们上淘宝买东西的订单 ID，就是一种分布式 ID。淘宝，前期的订单 id 好像是 14 位，现在好像已经是 16 位，或者 18 位了吧。
五大分布式ID生成器优缺点及对比
五大分布式ID生成器优缺点及对比
以我们公司的订单 ID 为例，它有这几个特点。
针对第五项，浅显的问题就是不能让非核心运营者知道每天的订单量等信息。如果 ID 是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定 URL 即可；如果是订单号就更危险了，竞对可以直接知道我们一天的订单量。所以在一些应用场景下，会需要 ID 无规则、不规则。
所以，设计一个好的分布式 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 的缺点：
snowflake 我就不在介绍了，我直接说它的优点：
缺点：
MongDB 的 ObjectID 可以算作是和snowflake类似方法，通过“时间+机器码+pid+inc”共12个字节，通过4+3+2+3的方式最终标识成一个24长度的十六进制字符。
支持多种不同模式的生成策略
号段模式：该模式需要建 DB 表, 需要有专门的服务来提供获取 id 的接口, 存在网络延迟
Snowflake 模式：为了追求更高的性能，需要通过 RPC Server 来部署 Leaf 服务，那仅需要引入 leaf-core 的包，把生成 ID 的 API 封装到指定的 RPC 框架中即可
缺点，可能就是相对来说比较复杂。
sharding-jdbc 是一个开源的主键生成组件。它的特点是简单易用，可以指定 workerId 或者不指定, 直接通过 jar 的方式引入即可。看它的名字就知道，它需要 DB 支持。
uid-generator 是百度开源的一个分布式 ID 生成器。需要建 DB 表, 需要有专门的服务来提供获取 id 的接口, 存在网络延迟。