最全常见分布式ID生成方案

分布式ID需求背景

• 分布式ID用于在数据量庞大、分库分表后的场景，确保数据记录的唯一性和避免数据冲突。

1. UUID

• 实现原理：由32位16进制数和4个“-”组成，基于时间戳、硬件标识符、随机数生成。
• 优点：本地生成，无需网络，生成性能高。
• 缺点：无序、不适合索引、ID长，存储效率低。
• 网络依赖性：无。

2. 数据库单点自增序列

• 实现原理：利用中央数据库表的自增主键生成ID。
• 优点：简单可靠，保证顺序性。
• 缺点：单点风险，性能瓶颈，不适合高并发。
• 网络依赖性：高。

3. 数据库集群下递增序列

• 实现原理：集群模式，每台数据库生成自增ID，设置起始值和步长。
• 优点：解决单点故障问题。
• 缺点：不利于扩容，高并发下性能问题，可能导致ID不连续。
• 网络依赖性：高。

4. 数据库号段模式

• 实现原理：应用服务节点从中央数据库获取ID段，本地缓存使用。
• 优点：减少数据库访问压力，提高性能。
• 缺点：存在单点故障风险，可能导致ID浪费。
• 网络依赖性：相对较低。

5. 雪花算法（Twitter Snowflake）

• 实现原理：64位long类型ID，基于时间戳、节点机器ID、序列号。
• 优点：ID有时间顺序，生成快。
• 缺点：依赖机器时钟，可读性差。
• 网络依赖性：通常无需网络交互。

6. Redis集群使用自增命令

• 实现原理：利用Redis的INCR和INCRBY命令生成有序ID。
• 优点：快速、简单、支持高并发。
• 缺点：依赖外部Redis服务，需要额外维护。
• 网络依赖性：高。

7. 利用Zookeeper生成唯一ID

• 实现原理：通过Zookeeper的znode数据版本生成序列号。
• 优点：保证ID唯一性和顺序性，适合分布式环境。
• 缺点：增加系统复杂性，需要外部依赖。
• 网络依赖性：高。

框架实现示例

• 美团Leaf-segment：双buffer，异步预分发方式生成ID。
• 滴滴Tingid：基于号段模式，支持多主节点，内存中生成ID。
• 微信序列号生成方案：与用户uin绑定，分号段共享存储。
• 阿里Tddl-sequence：基于DB数据段算法，本地生成序列。
• 百度UidGenerator：基于Snowflake算法，支持自定义位数和生成策略。