「这是我参与2022首次更文挑战的第9天，活动详情查看：2022首次更文挑战」。

在聊分布式ID的之前，我们先思考一下为什么要有分布式ID，比如我们数据库做分库分表后，那么我们如果使用数据库的自增ID，那么每个表中自增ID肯定会重复。我们应该需要一个全局性的唯一ID，那么就需要一个ID生成的方案。除了数据库比如优惠券ID和订单ID。都要保证全局唯一性。

一、分布式ID的特性

唯一性：确保生成的ID是全网唯一的。

有序递增性：确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的。

高可用性：确保任何时候都能正确的生成ID。

高性能：确保生成性能满足业务需求

带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。

二、分布式ID生成方案

UUID

算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。优点：本地生成，生成简单，性能好，没有高可用风险

缺点：长度过长，存储冗余，且无序不可读，查询效率低

数据库自增ID

使用数据库的id自增策略，如 MySQL 的 auto_increment。并且可以使用两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。

优点：数据库生成的ID绝对有序，高可用实现方式简单缺点：需要独立部署数据库实例，成本高，有性能瓶颈

批量生成ID

一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值。

优点：避免了每次生成ID都要访问数据库并带来压力，提高性能缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续

Redis生成ID

Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。

优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度；需要编码和配置的工作量比较大。

考虑到单节点的性能瓶颈，可以使用 Redis 集群来获取更高的吞吐量。假如一个集群中有5台

Redis。可以初始化每台 Redis 的值分别是1, 2, 3, 4, 5，然后步长都是 5。

Twitter的snowﬂake算法（重点）

Twitter 利用 zookeeper 实现了一个全局ID生成的服务 Snowﬂake

如上图的所示，Twitter 的 Snowﬂake 算法由下面几部分组成：

1位符号位：

由于 long 类型在 java 中带符号的，最高位为符号位，正数为 0，负数为 1，且实际系统中所使用的ID一般都是正数，所以最高位为 0。

41位时间戳（毫秒级）：

需要注意的是此处的 41 位时间戳并非存储当前时间的时间戳，而是存储时间戳的差值（当前时间戳 - 起始时间戳），这里的起始时间戳一般是ID生成器开始使用的时间戳，由程序来指定，所以41位毫秒时间戳最多可以使用。

10位数据机器位：

包括5位数据标识位和5位机器标识位，这10位决定了分布式系统中最多可以部署 1 << 10 = 1024

s个节点。超过这个数量，生成的ID就有可能会冲突。

12位毫秒内的序列：

这 12 位计数支持每个节点每毫秒（同一台机器，同一时刻）最多生成 1 << 12 = 4096个ID加起来刚好64位，为一个Long型。

优点：高性能，低延迟，按时间有序，一般不会造成ID碰撞缺点：需要独立的开发和部署，依赖于机器的时钟

百度UidGenerator

UidGenerator是百度开源的分布式ID生成器，基于于snowﬂake算法的实现，看起来感觉还行。不过，国内开源的项目维护性真是担忧。

美团Leaf

Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。

分布式ID的生成方案