浅谈分布式 ID 的生成策略：从数据库自增到雪花算法 --记录我的 Java 进阶之路第一篇

予枫
25 阅读6分钟

大家好，我是予枫 。在掘金社区潜水很久了，一直以来都是通过各位大佬的文章来解决问题、提升认知。但在学习的过程中，我愈发感觉到“纸上得来终觉浅”，单纯的阅读往往会让人产生掌握了的错觉。

于是，我决定开启自己的博客之旅，将所学、所思、所悟沉淀成文字。这篇关于 分布式 ID 生成方案 的分享，是我迈出的第一步。由于水平有限，文中难免会有理解不到位或者偏颇的地方。非常期待各位大佬能不吝赐教，在评论区留下您的建议或批评，您的每一份反馈对我来说都是莫大的进步动力。 让我们一起在技术的道路上并肩前行！（附一张超喜欢的角色壁纸！） 1a283c41e6b089c5a748f2a72f279b0d.jpg

为什么选择“分布式 ID”作为开篇？ 最近在深入学习 Java 后端和 Redis 中间件时，遇到了一个非常经典且重要的问题：在分布式场景下，如何生成一个全局唯一的 ID？

在单体架构时代，我们习惯使用数据库的自增 ID（Auto Increment），但在分库分表、微服务的高并发场景下，这种方式由于性能瓶颈和单点问题，显然已经力不从心。

今天这篇博客就来总结一下目前业界最主流的 4 种全局唯一 ID 生成策略，分析它们的原理、优缺点以及适用场景。

什么样的 ID 才是好 ID？

在设计 ID 生成器之前，我们需要明确“好 ID”的标准。通常有以下几个核心要求：

  1. 全局唯一性：这是最基本的要求，不能出现重复。
  2. 高可用 & 高性能：生成 ID 的动作非常频繁，不能成为系统的瓶颈，且服务要足够稳定。
  3. 递增性（趋势有序） ：这一点常被忽略。对于使用 MySQL（InnoDB 引擎）的系统，主键建议保持递增，因为 InnoDB 使用 B+ 树索引，有序的主键写入能避免频繁的“页分裂”，极大提升写入性能。
  4. 安全性：某些业务场景下（如订单号），ID 不应过于明显地暴露业务量（比如不能让人轻易猜出你一天有多少单）。

方案一：UUID (Universally Unique Identifier)

​

UUID 是最简单、最暴力的方案。JDK 原生支持，一行代码搞定。

代码实现

public static void main(String[] args) {
    // 生成一个 UUID，并去掉中间的横线
    String id = UUID.randomUUID().toString().replace("-", "");
    System.out.println("UUID: " + id);
}

优缺点分析

  • 优点：

    • 性能极高：完全在本地生成，没有网络消耗。
    • 使用简单：不依赖任何外部组件（DB、Redis 等）。

  • 缺点：

    • 无序性（致命伤） ：UUID 是无序的字符串。如果作为 MySQL 主键，会导致大量的数据页分裂和移动，严重拖慢插入速度。
    • 存储成本高：32 个字符（或 16 字节），相比 Long 类型特别占空间，也会导致索引变大。
    • 信息不安全：完全随机，无法携带时间或业务含义。

👉 结论：适合生成 Token、Session ID 或非数据库主键的场景。坚决不建议用作 MySQL 的主键。

方案二：数据库自增 (Database Auto-Increment)

利用 MySQL 的 auto_increment 特性，或者 Oracle 的 Sequence。

原理

应用服务向数据库插入数据，数据库自动累计 ID。

优缺点分析

  • 优点：

    • 简单：利用现有数据库功能，成本低。
    • 单调递增：对索引非常友好，查询效率高。

  • 缺点：

    • 并发瓶颈：在高并发下，数据库往往是最大的瓶颈。
    • 分库分表麻烦：如果未来需要分库，不同库的自增 ID 会重复。虽然可以通过设置不同的“步长”（Step）来解决（如 DB1 生成 1,3,5... DB2 生成 2,4,6...），但这增加了扩容和维护的难度。
    • 单点故障：数据库挂了，整个 ID 生成服务就不可用了。

👉 结论：适合并发量不高的中小项目，或者不需要分库分表的数据表。

方案三：Redis 自增策略

Redis 是单线程处理命令的，其 INCR 命令是原子的，天生适合做计数器。这是我最近在学 Redis 时觉得非常有意思的一个应用点。

代码思路 (Java + RedisTemplate)

为了避免 ID 被推测出业务量，通常会结合“时间戳”使用。

格式示例：yyyyMMdd + Redis自增值。

// 伪代码示例
public long generateId(String keyPrefix) {
    // 1. 生成时间戳部分
    String dateStr = DateTimeFormatter.ofPattern("yyyyMMdd").format(LocalDate.now());
    
    // 2. 利用 Redis 原子递增
    // key 举例: icr:order:20251216
    Long increment = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + dateStr);
    
    // 3. 拼接 ID (实际生产中通常需要通过位运算或字符串填充补齐位数)
    return Long.parseLong(dateStr + String.format("%06d", increment));
}

优缺点分析

  • 优点：

    • 高性能：基于内存操作，吞吐量远高于数据库。
    • 有序递增：对数据库索引友好。
    • 灵活：可以方便地把日期、业务类型编排进 ID 中。

  • 缺点：

    • 强依赖组件：如果 Redis 挂了，ID 生成服务就断了（需要配置 Sentinel 或 Cluster 高可用）。
    • 运维成本：引入了额外的中间件维护成本。

👉 结论：非常适合高并发的业务场景（如秒杀、订单生成），且生成的 ID 具有业务含义。

方案四：雪花算法 (Snowflake)

这是目前分布式系统中最流行、最成熟的方案，由 Twitter 开源。它的核心思想是将一个 64 位的 long 型数字切割成不同的部分。

结构图解 (64 bit)

  • 1 bit：符号位（固定为0）。
  • 41 bits：时间戳（毫秒级，可以使用 69 年）。
  • 10 bits：机器 ID（支持 1024 个节点）。
  • 12 bits：序列号（同一毫秒内支持生成 4096 个 ID）。

代码实现

通常不需要自己手写位运算，推荐使用成熟的工具包，例如 Hutool。

// 引入 Hutool 依赖后
public class IdTest {
    public static void main(String[] args) {
        // 参数1: 终端ID, 参数2: 数据中心ID
        Snowflake snowflake = IdUtil.getSnowflake(1, 1);
        long id = snowflake.nextId();
        System.out.println("Snowflake ID: " + id);
    }
}

优缺点分析

  • 优点：

    • 极高并发：每秒可生成几百万个 ID。
    • 不依赖网络：本地生成（除了启动时校验机器 ID），无单点故障。
    • 趋势递增：整体按时间递增，索引性能好。

  • 缺点：

    • 时钟回拨问题：严重依赖服务器时间。如果服务器时间被回调（比如校准时间），算法可能会生成重复 ID。

👉 结论：几乎所有互联网大厂的主流选择，适合超大规模的分布式系统。

总结对比

最后，用一张表来总结这几种策略：

策略唯一性有序性性能依赖组件核心痛点
UUID高无极高无索引性能差，ID太长
DB自增高严格有序低数据库并发瓶颈，扩展麻烦
Redis高严格有序高Redis依赖 Redis 高可用
Snowflake高趋势有序极高无时钟回拨问题

个人建议：

如果你是初学者或者项目规模较小，Redis 自增是一个非常好的练手方案，既能满足性能要求，又能加深对 Redis 的理解。而如果是企业级的大型项目，Snowflake（配合 Hutool 等工具库）则是目前的最优解。

希望这篇总结对大家有所帮助！如果你有更好的方案，欢迎在评论区交流。

本文由一名热爱技术的研二学生整理，持续分享 Java 后端与算法学习心得。

​

avatar
文章
阅读
粉丝