分布式ID的特性

1. 唯一性：确保生成的ID是全网唯一的。
2. 有序递增性：确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的。
3. 高可用性：确保任何时候都能正确的生成ID。
4. 带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。

概览

1.UUID（不推荐）

算法的核心思想是结合机器的网卡、当地时间、一个随机数来生成UUID。

优点：本地生成，生成简单，性能好，没有高可用风险

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

2.数据库自增ID（建议）

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

优点：数据库生成的ID绝对有序，高可用实现方式简单

缺点：需要独立部署数据库实例，成本高，有性能瓶颈

3. 批量生成ID（建议）

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

优点：避免了每次生成ID都要访问数据库并带来压力，提高性能

缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续

4. Redis生成ID（推荐）

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

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

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

考虑到单节点的性能瓶颈，可以使用 Redis 集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台 Redis 的值分别是1, 2, 3, 4, 5，然后步长都是 5。

5. Twitter的snowflflake算法（重点）

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

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

• 1位符号位：

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

• 41位时间戳（毫秒级）：

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

• 10位数据机器位：

阿里内部资料包括5位数据标识位和5位机器标识位，这10位决定了分布式系统中最多可以部署 1 << 10 = 1024个节点。超过这个数量，生成的ID就有可能会冲突。

• 12位毫秒内的序列：

这 12 位计数支持每个节点每毫秒（同一台机器，同一时刻）最多生成 1 << 12 = 4096个ID

加起来刚好64位，为一个Long型。

优点：高性能，低延迟，按时间有序，一般不会造成ID碰撞

缺点：需要独立的开发和部署，依赖于机器的时钟

6. 百度UidGenerator

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

7. 美团Leaf

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

总结

一般推荐多种方案组合使用，比如通过Redis的方案+数据库的方案进行双保障，因为Redis出现异常情况，可以有兜底方案。选型上面推荐用雪花算法、Redis自增生成、提前生成的方案优先使用。