高并发分布式系统中生成全局唯一ID汇总

发表于 2023-01-09 更新于 2026-04-20

一、概述

在分布式系统中，特别是在分库分表场景下，生成全局唯一ID是一个关键的技术挑战。单纯的生成全局ID并不困难，但生成的ID需要满足分布式系统的特定要求：

无单点故障：ID生成服务必须具备高可用性
时间有序性：ID应包含时间信息或按时间排序，便于索引优化和冷热数据分离
分片可控性：能够控制ShardingId，使相关数据位于同一分片，提高查询和修改效率
长度适中：最好为64bit，便于使用long类型操作，避免组件兼容性问题

本文将详细介绍几种主流的全局唯一ID生成方案。

二、Snowflake算法（Twitter方案）

2.1 背景

Twitter在将存储系统从MySQL迁移到Cassandra时，由于Cassandra没有内置的顺序ID生成机制，开发了Snowflake全局唯一ID生成服务。

2.2 算法结构

Snowflake生成的ID为64位，结构如下：

1	0 \| 41位时间戳 \| 10位机器标识 \| 12位序列号

各字段说明：

符号位：1位，始终为0
时间戳：41位，精确到毫秒，可使用69年（从自定义起始时间开始）
机器标识：10位，最多支持1024个节点
序列号：12位，每个节点每毫秒可生成4096个ID

2.3 核心原理

![[Snowflake算法原理图.png]]

2.4 Java实现示例

public class IdWorker {
    private final long workerId;
    private final static long twepoch = 1288834974657L;
    private long sequence = 0L;
    private final static long workerIdBits = 4L;
    public final static long maxWorkerId = -1L ^ -1L << workerIdBits;
    private final static long sequenceBits = 10L;
    private final static long workerIdShift = sequenceBits;
    private final static long timestampLeftShift = sequenceBits + workerIdBits;
    public final static long sequenceMask = -1L ^ -1L << sequenceBits;
    private long lastTimestamp = -1L;

    public IdWorker(final long workerId) {
        super();
        if (workerId > this.maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format(
                "worker Id can't be greater than %d or less than 0",
                this.maxWorkerId));
        }
        this.workerId = workerId;
    }

    public synchronized long nextId() {
        long timestamp = this.timeGen();
        if (this.lastTimestamp == timestamp) {
            this.sequence = (this.sequence + 1) & this.sequenceMask;
            if (this.sequence == 0) {
                timestamp = this.tilNextMillis(this.lastTimestamp);
            }
        } else {
            this.sequence = 0;
        }
        
        if (timestamp < this.lastTimestamp) {
            try {
                throw new Exception(
                    String.format(
                        "Clock moved backwards. Refusing to generate id for %d milliseconds",
                        this.lastTimestamp - timestamp));
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        
        this.lastTimestamp = timestamp;
        long nextId = ((timestamp - twepoch) << timestampLeftShift)
            | (this.workerId << this.workerIdShift) | (this.sequence);
        return nextId;
    }

    private long tilNextMillis(final long lastTimestamp) {
        long timestamp = this.timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = this.timeGen();
        }
        return timestamp;
    }

    private long timeGen() {
        return System.currentTimeMillis();
    }
}

2.5 优缺点分析

优点：

高性能，低延迟
独立应用，不依赖外部服务
ID按时间有序

缺点：

需要独立开发和部署
时钟回拨问题需要处理
机器标识需要管理

三、Flickr数据库方案

3.1 方案概述

Flickr利用MySQL的自增ID特性，通过auto_increment、replace into和MyISAM引擎实现全局ID生成。

3.2 实现步骤

创建专用表

CREATE TABLE Tickets64 (
    id bigint(20) unsigned NOT NULL auto_increment,
    stub char(1) NOT NULL default '',
    PRIMARY KEY (id),
    UNIQUE KEY stub (stub)
) ENGINE=MyISAM

生成ID操作

在事务会话中执行：

1 2	REPLACE INTO Tickets64 (stub) VALUES ('a'); SELECT LAST_INSERT_ID();

高可用配置

通过配置两台MySQL服务器，设置不同的起始值和步长来生成奇偶数ID：

# TicketServer1配置
auto-increment-increment = 2
auto-increment-offset = 1

# TicketServer2配置
auto-increment-increment = 2
auto-increment-offset = 2

客户端通过轮询方式获取ID。

3.3 优缺点分析

优点：

利用数据库自增ID机制，可靠性高
生成的ID有序
实现相对简单

缺点：

需要独立的MySQL实例，资源消耗大
性能受数据库限制
存在单点故障风险（需额外配置高可用）

四、UUID方案

4.1 基本概念

UUID（Universally Unique Identifier）生成的是32位16进制格式的字符串，转换为byte数组为16个字节，即128bit。

4.2 生成原理

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

4.3 唯一性保证

理论上，如果一台机器每秒产生1000万个GUID，可以保证（概率意义上）3240年不重复。

4.4 优缺点分析

优点：

本地生成，无需远程调用，延迟低
扩展性好，基本无性能上限
全球唯一性保证

缺点：

无法保证趋势递增
长度过长（128bit），作为主键时索引效率低
常见优化方案存在局限性：
- 转化为两个uint64整数存储
- 折半存储（可能影响唯一性）

五、基于Redis的分布式ID生成器

5.1 实现原理

利用Redis的Lua脚本执行功能，在每个节点上通过Lua脚本生成唯一ID。

5.2 ID结构

生成的ID为64位，结构如下：

41位时间戳：精确到毫秒，可使用41年
12位逻辑分片ID：最大分片ID为4095
10位自增长ID：每个节点每毫秒最多生成1024个ID

5.3 生成示例

假设：

GTM时间：Fri Mar 13 10:00:00 CST 2015
毫秒数：1426212000000
分片ID：53
自增长序列：4

生成ID计算：

1	5981966696448054276 = 1426212000000 << 22 + 53 << 10 + 4

5.4 Redis命令使用

Redis提供TIME命令获取服务器上的秒数和微秒数。Lua脚本返回四元组：(second, microSecond, partition, seq)

客户端处理逻辑：

1 2	long id = ((second * 1000 + microSecond / 1000) << (12 + 10)) + (shardId << 10) + seq;

六、MongoDB ObjectId方案

6.1 设计考虑

MongoDB的_id字段需要满足分布式环境下的全局唯一性要求，因此不能使用自增主键，而是采用ObjectId对象。

6.2 ObjectId结构

ObjectId使用12字节存储空间，结构如下：

字节位置	0-3	4-6	7-8	9-11
内容	时间戳	机器ID	进程ID	计数器

各字段说明：

时间戳（4字节）：从标准纪元开始的秒数
机器ID（3字节）：服务器主机标识，通常是主机名的散列值
进程ID（2字节）：mongod进程标识符
计数器（3字节）：自动增加的计数器，每个进程独立

6.3 唯一性保证机制

时间戳：保证秒级唯一性
机器ID：考虑分布式环境，避免时钟同步问题
进程ID：保证同一服务器上多个mongod实例的唯一性
计数器：保证同一秒内的唯一性（最多16777216个）

6.4 生成位置

_id可以在服务器端生成，也可以在客户端生成。客户端生成可以降低服务器端压力。

七、方案对比

方案	优点	缺点	适用场景
Snowflake	高性能、有序、独立	需独立部署、时钟问题	大规模分布式系统
Flickr数据库	简单、可靠、有序	性能受限、资源消耗大	中小规模系统
UUID	全球唯一、无中心化	无序、存储效率低	需要全局唯一标识
Redis方案	性能好、可扩展	依赖Redis、配置复杂	Redis环境下的系统
MongoDB ObjectId	内置支持、分布式友好	MongoDB专用	MongoDB数据库系统

八、选择建议

8.1 考虑因素

系统规模：大规模系统推荐Snowflake，中小规模可考虑数据库方案
性能要求：高并发场景选择Snowflake或Redis方案
有序性需求：需要有序ID时选择Snowflake或数据库方案
技术栈：现有技术栈影响方案选择（如已使用MongoDB）

8.2 最佳实践

Snowflake：适合需要高性能、有序ID的大规模分布式系统
数据库方案：适合对数据库依赖较强的系统，实现简单
混合方案：可根据业务场景组合使用不同方案

九、总结

全局唯一ID生成是分布式系统中的基础且重要的技术。不同的方案各有优劣，选择时需要综合考虑系统规模、性能要求、有序性需求和技术栈等因素。

在实际应用中，建议：

明确业务需求，选择最适合的方案
考虑系统的扩展性和维护成本
做好异常处理，特别是时钟回拨等问题
定期评估和优化ID生成策略

随着技术发展，新的ID生成方案不断涌现，但核心原则不变：在保证唯一性的前提下，追求更高的性能和更好的扩展性。

参考资源：

Twitter Snowflake官方文档
Flickr技术博客
MongoDB官方文档
Redis官方文档

如何在高并发分布式系统中生成全局唯一Id - 滴答的雨 - 博客园

Excerpt
如何在高并发分布式系统中生成全局唯一Id。
1、使用数据库自增Id
2、单独开一个数据库，获取全局唯一的自增序列号或各表的MaxId
3、Sequence特性
4、通过数据库集群编号+集群内的自增类型两个字段共同组成唯一主键
5、通过设置每个集群中自增 ID 起始点
6、GU

最近公司用到，并且在找最合适的方案，希望大家多参与讨论和提出新方案。我和我的小伙伴们也讨论了这个主题，我受益匪浅啊……

博文示例：

1. GUID生成Int64值后是否还具有唯一性测试

2. Random生成高唯一性随机码

今天分享的主题是：如何在高并发分布式系统中生成全局唯一Id。

但这篇博文实际上是“半分享半讨论”的博文：

1) 半分享是我将说下我所了解到的关于今天主题所涉及的几种方案。

2) 半讨论是我希望大家对各个方案都说说自己的见解，更加希望大家能提出更好的方案。（我还另外提问在此：http://q.cnblogs.com/q/53552/）

我了解的方案如下……………………………………………………………………

1、使用数据库自增Id

优势：编码简单，无需考虑记录唯一标识的问题。

缺陷：

1) 在大表做水平分表时，就不能使用自增Id，因为Insert的记录插入到哪个分表依分表规则判定决定，若是自增Id，各个分表中Id各自增长就会重复

2) 在业务上操作父、子表（即关联表）插入时，需要在插入数据库之前获取max(id)用于标识父表和子表关系，若存在并发获取max(id)的情况，max(id)会同时被别的线程获取到。

3) DB数据记录都是可以根据ID号进行推测出来，对于一些数据敏感的场景，不建议采用

结论：适合小应用，无需分表，低并发。

2、单独开一个数据库，获取全局唯一的自增序列号或各表的MaxId

使用MaxId表存储各表的MaxId值

专门一个数据库，记录各个表的MaxId值，建一个存储过程来取Id，逻辑大致为：开启事物，对于在表中不存在记录，直接返回一个默认值为1的键值，同时插入该条记录到table_key表中。而对于已存在的记录，key值直接在原来的key基础上加1更新到MaxId表中并返回key。（给table_key中为每个表初始化一条key为1的记录，这样就不用每次if来判断了—@辉_辉提议）

使用此方案的问题是：每次的查询MaxId是一个性能损耗；

详细可参考：《使用MaxId表存储各表的MaxId值，以获取全局唯一Id》

我截取此文中的sql语法如下：

第一步：创建表

create table table_key

(

table_name varchar(50) not null primary key,

key_value int not null

)

第二步：创建存储过程来取自增ID

create procedure up_get_table_key

(

@table_name varchar(50),

@key_value int output

)

as

begin

begin tran

declare @key int

set @key=1

if not exists(select table_name from table_key where table_name=@table_name)

begin

insert into table_key values(@table_name,@key)

end

else

begin

select @key=key_value from table_key with (nolock) where table_name=@table_name

set @key=@key+1

update table_key set key_value=@key where table_name=@table_name

end

set @key_value=@key

commit tran

if @@error>0

rollback tran

end

2. （@乐活的CodeMonkey）提醒提高获取ID时存储过程的隔离级别，避免读取到未提交事务导致并发ID重复的问题。（MSSQL事务隔离级别详解）

eg：

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

GO

BEGIN TRANSACTION;

……

GO

COMMIT TRANSACTION;

3. （@土豆烤肉）存储过程中不使用事物，一旦使用到事物性能就急剧下滑。直接使用UPDATE获取到的更新锁，即SQL SERVER会保证UPDATE的顺序执行。（已在用户过千万的并发系统中使用）

create procedure [dbo].[up_get_table_key]

(

@table_name varchar(50),

@key_value int output

)

as

begin

SET NOCOUNT ON;

DECLARE @maxId INT

UPDATE table_key

SET @maxId = key_value,key_value = key_value + 1

WHERE table_name=@table_name

SELECT @maxId

end

结论：适用中型应用，此方案解决了分表，关联表插入记录的问题。但是无法满足高并发性能要求。存在单点问题

改进方案：时间信息 + 缓存总的maxid （@wee616 提议）

从redis中用lpop指令取指定key值的数据。（lpop：移除并返回列表的头元素）
  如果将指定key值的数据取完了，会触发初始化。
  初次初始化：
1）用for update锁表，存储最小值1和最大值50到数据库中。
      2）将这50个数字放入redis中。
  下次初始化：
      1）用for update锁表，存储最小值51和最大值100到数据库中。
      2）将这50个数字放入redis中。

数据库每天有脚本定时清理这个表，每天都将最小值归0，避免最大值过大。

结论：适合大型应用，生成Id顺序性，可读性比较好。

3、 Sequence特性

这个特性在SQL Server 2012、Oracle中可用。这个特性是数据库级别的，允许在多个表之间共享序列号。它可以解决分表在同一个数据库的情况，但倘若分表放在不同数据库，那将共享不到此序列号。（eg：Sequence使用场景：你需要在多个表之间公用一个流水号。以往的做法是额外建立一个表，然后存储流水号）