文章总结： 文档详细介绍了微服务分布式全局ID生成方式，包括UUID、数据库自增ID、Redis自增ID、Snowflake等方案，分析了各自的原理、优缺点和适用场景，并提供了选型建议。关键发现是不同方案在唯一性、有序性、性能等方面有差异，应根据系统规模和需求选择合适方案，如高并发场景推荐Snowflake，中小规模可用号段模式。 综合评分： 88 文章分类： 应用安全,数据安全,安全建设,解决方案,安全工具

微服务分布式全局ID生成方式

原创

静观云起

码云精炼

2025年12月13日 15:45 广东

分布式微服务全局ID生成，是指在分布式系统环境下，为每一条数据、每一个请求或每一个实体生成一个全局唯一、趋势递增(可选)、高性能、高可用的ID，以下是常见的分布式全局 ID 生成方式及其特点。

一  UUID(Universally Unique Identifier)

*原理：基于时间戳、机器标识、随机数等生成128(16个字节)位唯一标识，它由32个十六进制数字组成，被4个连字符 “-“ 分隔成，总共36个字符(含连字符)，常见格式如 550e8400-e29b-41d4-a716-446655440000*

优点:

✅实现简单，本地生成，无需网络交互

✅保证全局唯一性

缺点：

✅无序，不适合作为数据库主键(影响索引性能)

✅字符串较长，存储和传输成本高

适用场景：非严格排序、对性能要求不高的唯一标识场景

二 数据库自增ID

原理：依赖数据库的自增字段(如 MySQL AUTO_INCREMENT)生成唯一 ID

优化：号段模式(Segment)

不是每次生成ID都访问数据库，而是由数据库一次性分配一个”号段”(即一段连续的 ID 范围)，应用程序将这个号段缓存在内存中，然后在内存中自行分配 ID，用完后再向数据库申请下一个号段。由数据库统一分配一个ID号段(如 1~1000)，应用缓存并在本地自增，用完后再次申请新号段。

代表中间件：美团的 Leaf-segment

优点：

✅ID是数字且基本有序，数字类型，存储高效，相比 UUID，更适合做数据库主键，对索引友好。

✅号段模式减少数据库访问频次,传统自增ID每生成一个ID就要访问一次数据库，而号段模式一次申请一批，极大提升性能。

✅支持多实例部署时，每个服务实例申请不同的号段范围，避免冲突**

缺点：

✅强依赖数据库，存在单点问题(可通过多DB主从解决）

✅不保证严格递增

适用场景：中小规模系统，对ID有序性有一定要求。

三 Redis自增ID

*原理：利用Redis的原子性INCR或INCRBY命令生成唯一递增ID。*

优化：可结合时间戳前缀，如 时间戳 + Redis自增值

优点：

✅性能极高，支持分布式

✅可灵活定制ID格式

缺点：

✅依赖Redis的高可用部署

✅若未合理设计，可能不保证严格有序或可读性差

适用场景：高并发、对性能要求较高的业务

四 Snowflake(雪花算法，Twitter提出)

原理：64位Long型ID，结构如下：

符号位(1位，固定0) + 时间戳(41位，毫秒级，可用69年) + 数据中心ID(5位) + 机器ID(5位) + 序列号(毫秒内自增，12位)

| 部分 | 位数 | 说明 | | — | — | — | | 符号位 | 1 | 固定0(保证是正数) | | 时间戳 | 41 | 毫秒级时间差(约69年范围) | | 数据中心ID | 5 | 最多支持32个数据中心 | | 机器ID | 5 | 最多支持32台机器 | | 序列号 | 12 | 每毫秒最多4096个ID |

这些二进制位组合后转换成一个64位long整数，再以十进制字符串展示出来，通常是18~19 位数字。

优点：

✅全局唯一、趋势递增(有利于数据库索引）

✅不依赖数据库，性能高，可分布式部署

✅每秒可生成数百万个ID

缺点：

✅依赖机器时钟，时钟回拨会导致ID冲突(需做回拨处理)

✅需要为不同服务节点分配唯一的workerId和datacenterId

适用场景：分布式系统、高并发、对ID有序性有要求的场景(如订单、消息、日志等)

何如保证为服务实例的数据中心ID和机器ID组合是唯一的？

1. 在Docker/K8s等动态环境中，强烈建议使用Redis/ZooKeeper动态分配workerId和datacenterId，或直接使用Leaf等开源框架

2. 在传统物理机/虚拟机部署中，可以手动配置，但要严格保证每个实例的(datacenterId + workerId)唯一

3. datacenterId 可按实际部署区域划分(如机房、地域)，workerId按实例划分

4. 务必避免不同服务实例使用相同的workerId，否则会导致ID重复！

五 百度UID-Generator

原理：基于Snowflake思想，但通过RingBuffer预生成ID提升性能，解决时钟回拨问题更优雅

优点：

✅支持自定义WorkerId分配策略

使用场景：适合对性能和可用性要求更高的业务

六 美团 Leaf

Leaf-segment：

基于数据库号段模式，支持高可用、多DB主备

Leaf-snowflake：

基于Snowflake，解决了时钟回拨问题，支持ZK动态分配 workerId

特点：高可用、易接入、生产级方案

七 滴滴 TinyID

基于数据库号段模式，支持多DB、多实例，提供HTTP和Java SDK

使用场景：适合对 ID 生成服务化有需求的团队使用

八 MongoDB ObjectId

12 字节的BSON类型ID，BSON 类型是 MongoDB 使用的一种二进制编码的数据格式，全称为Binary JSON，它是JSON格式的扩展，支持更多数据类型，不仅包含 JSON 原生支持的字符串、数字、布尔值、数组和对象，还增加了如日期、二进制数据、ObjectId 等类型。包含时间戳、机器标识、进程ID和计数器

Unix 时间戳秒级(4个字节) + 机器标识 + 进程 ID(5个字节) + 自增计数器(3个字节)

优点：

✅分布式友好，不同服务器、不同进程生成的ID几乎不会重复。**

✅无需中心化协调，不需要依赖数据库自增或第三方服务来保证唯一性。**

✅高概率唯一，冲突概率极低，适合大多数业务场景。**

✅自带时间信息，前 4 字节是时间戳，可用于粗略排序或判断创建时间。**

缺点：

✅非连续，ID不是按顺序生成的，不能做分页排序优化时需注意。**

✅不可读，是一串十六进制字符(如**64f1a2b3e4c56789ab123456)，不适合直接展示给用户。

✅非自解释，不像UUID有版本标识，但结构固定且通用。**

使用场景：适合使用MongoDB的系统，但不适合需要数字类型或强排序的场景

九  选型建议

| | | | | | — | — | — | — | | 方案 | 是否有序 | 依赖 | 使用场景 | | UUID | 乱序 | 无 | 简单唯一标识，无需排序 | | 数据库自增 | 严格递增 | 数据库 | 单机或小规模，简单场景 | | 号段模式 | 相对有序 | 数据库 | 中小规模，优化数据库压力 | | Redis自增 | 递增 | Redis | 高并发，允许依赖 Redis | | Snowflake | 趋势递增 | 时钟 | 分布式系统，高并发，有序ID | | UID-Generator | 有序 | 无 | 高性能，生产级，改进 Snowflake | | 美团Leaf | 有序 | DB/ZK | 企业级、高可用、多种实现 | | 滴滴TinyID | 有序 | DB | 服务化ID生成，简单易用 |

查看原文：《微服务分布式全局ID生成方式》