在分布式系统中，有一些场景需要使用全局唯一 ID ，可以和业务场景有关，比如支付流水号，也可以和业务场景无关，比如分库分表后需要有一个全局唯一 ID，或者用作事务版本号、分布式链路追踪等等，好的全局唯一 ID 需要具备这些特点：
- 全局唯一：这是最基本的要求，不能重复；
- 递增：有些特殊场景是必须递增的，比如事务版本号，后面生成的 ID 一定要大于前面的 ID ；有些场景递增比不递增要好，因为递增有利于数据库索引的性能；
- 高可用：如果是生成唯一 ID 的系统或服务，那么一定会有大量的调用，那么保证其高可用就非常关键了；
- 信息安全：如果 ID 是连续的，那么很容易被恶意操作或泄密，比如订单号是连续的，那么很容易就被看出来一天的单量大概是多少；
- 另外考虑到存储压力，ID 当然是越短越好。
那么分布式场景下有哪些生成唯一 ID 的方案呢？
利用数据库生成
先说最容易理解的方案，利用数据库的自增长序列生成：数据库生成唯一主键，并通过服务提供给其他系统；如果是小型系统，数据总量和并发量都不是很大的情况下，这种方案足够支撑。
如果每次生成一个 ID 可能会对数据库有压力，可以考虑一次性生成 N 个 ID 放入缓存中，如果缓存中的 ID 被取光，再通过数据库生成下一批 ID 。
- 优点： 理解起来最容易，实现起来也最简单。
- 缺点： 也非常明显了，每种数据库的实现不同，如果数据库需要迁移的话比较麻烦；最大的问题是性能问题，并发量到一定级别的时候这个方法估计会很难满足性能需求；另外通过数据库自增生成的 ID 携带的信息太少，只能起到一个标识的作用，同时自增 ID 也是连续的。
利用其他组件/软件/中间件生成
利用 Redis / MongoDB / zookeeper 生成：Redis 利用 incr 和 increby ；MongoDB 的 ObjectId；zk 通过 znode 数据版本；都可以生成全局的唯一标识码。
我们用 MongoDB 的 ObjectId 来举例：
{“_id”: ObjectId(“5d47ca7528021724ac19f745”)}
MongoDB 的 ObjectId 共占 12 个字节，其中：
- 3.2 之前的版本（包括 3.2）： 4 字节时间戳 + 3 字节机器标识符 + 2 字节进程 ID + 3字节随机计数器
- 3.2 之后版本： 4 字节时间戳 + 5 字节随机值 + 3 字节递增计数器
不管是老版本还是新版本，MongoDB 的 ObjectId 至少都可以保证集群内的唯一，我们可以搭建一个全局唯一 ID 生成的服务，利用 MongoDB 生成 ObjectId 并对外提供服务（MongoDB 的各语言驱动都实现了 ObjectId 的生成算法）。
- 优点： 性能高于数据库；可以使用集群部署；ID 内自带一些含义，比如时间戳；
- 缺点： 和数据库一样，需要引入对应的组件/软件，增加了系统的复杂度；最关键的是，这两种方案都意味着生成全局唯一 ID 的系统（服务），会成为一个单点，在软件架构中，单独就意味着风险；如果这个服务出现问题，那么所有依赖于这个服务的系统都会崩溃掉。
UUID
这个是分布式架构中，生成唯一标识码最常用的算法。为了保证 UUID 的唯一性，生成因素包括了MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素；UUID 有多个版本，每个版本的算法不同，应用范围也不同：
- Version 1： 基于时间的 UUID，是通过时间戳 + 随机数 + MAC地址得到；如果应用直接局域网内使用，可以使用 IP 地址替代 MAC 地址；高度唯一(MAC 地址泄漏，也是一个安全问题)。
- Version 2： DCE 安全的 UUID，把 Version 1 中的时间戳前 4 位置换为 POSIX 的 UID 或 GID ；高度唯一。
- Version 3： 基于名字的 UUID（MD5），通过计算名字和名字空间的 MD5 散列值得到；一定范围内唯一。
- Version 4： 随机 UUID，根据随机数或伪随机数生成 UUID；有一定概率重复。
- Version 5： 基于名字的UUID（SHA1），和 Version 3 类似，只是散列值计算使用SHA1算法；一定范围内唯一。
image
此外，还有很多优秀的互联网公司也提供了唯一 ID 生成的方案或框架，比如美团开源的 Leaf ，百度开源的 UidGenerator 等等。