今天分享一位读者去京东面试遇到的面试题：“为什么要分布式 ID？你项目中是怎么做的？”。

这篇文章我会说说自己的看法，详细介绍一下分布式 ID 相关的内容包括分布式 ID 的基本要求以及分布式 ID 常见的解决方案。

内容概览：华宇开户

个人能力有限。如果文章有任何需要补充/完善/修改的地方，欢迎在评论区指出，共同进步！

日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 对应且仅对应一个人，商品 ID 对应且仅对应一件商品，订单 ID 对应且仅对应一个订单。

我们现实生活中也有各种 ID，比如身份证 ID 对应且仅对应一个人、地址 ID 对应且仅对应

简单来说，ID 就是数据的唯一标识。

分布式 ID 是分布式系统下的 ID。分布式 ID 不存在与现实生活中，属于计算机系统中的一个概念。

我简单举一个分库分表的例子。

我司的一个项目，使用的是单机 华宇开户 MySQL 。但是，没想到的是，项目上线一个月之后，随着使用人数越来越多，整个系统的数据量将越来越大。单机 MySQL 已经没办法支撑了，需要进行分库分表（推荐 Sharding-JDBC）。

在分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？

这个时候就需要生成分布式 ID了。

分布式 ID 作为分布式系统中必不可少的一环，很多地方都要用到分布式 ID。

一个最基本的分布式 ID 需要满足下面这些要求：

除了这些之外，一个比较好的分布式 ID 还应保证：数据库主键自增

这种方式就比较简单直白了，就是通过关系型数据库的自增主键产生来唯一的 ID。

以 MySQL 举例，我们通过下面的方式即可。

1.创建一个数据库表。

字段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 字段创建了唯一索引，保证其唯一性。

2.通过 来插入数据。

插入数据这里，我们没有使用 而是使用 华宇开户 来插入数据，具体步骤是这样的：

这种方式的优缺点也比较明显：数据库号段模式

数据库主键自增这种模式，每次获取 ID 都要访问一次数据库，ID 需求比较大的时候，肯定是不行的。

如果我们可以批量获取，然后存在在内存里面，需要用到的时候，直接从内存里面拿就舒服了！这也就是我们说的 基于数据库的号段模式来生成分布式 ID。

数据库的号段模式也是目前比较主流的一种分布式 ID 生成方式。像滴滴开源的Tinyid[1] 就是基于这种方式来做的。不过，TinyId 使用了双号段缓存、增加多 db 支持等方式来进一步优化。

以 MySQL 举例，我们通过下面的方式即可。

1. 创建一个数据库表。

字段和字段主要用于获取批量 ID，获取的批量 id 为：。

字段主要用于解决并发问题（乐观锁）, 主要用于表示业务类型。

2. 先插入一行数据。

3. 通过 SELECT 获取指定业务下的批量唯一 ID

结果：

4. 不够用的话，更新之后重新 SELECT 即可。

结果：

相比于数据库主键自增的方式，数据库的号段模式对于数据库的访问次数更少，数据库压力更小。

另外，为了避免单点问题，你可以从使用主从模式来提高可用性。

数据库号段模式的优缺点:NoSQL

一般情况下，NoSQL 方案使用 Redis 多一些。我们通过 Redis 的 命令即可实现对 id 原子顺序递增。

为了提高可用性和并发，我们可以使用 Redis Cluster。Redis Cluster 是 Redis 官方提供的 Redis 集群解决方案（3.0+版本）。

除了 Redis Cluster 之外，你也可以使用开源的 Redis 集群方案Codis[2] （大规模集群比如上百个节点的时候比较推荐）。

除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。Redis 支持两种不同的持久化方式：快照（snapshotting，RDB）、只追加文件（append-only file, AOF）。并且，Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 开启）。

关于 Redis 持久化，我这里就不过多介绍。不了解这部分内容的小伙伴，可以看看 Redis 持久化机制详解[3]这篇文章。

Redis 方案的优缺点：

除了 Redis 之外，MongoDB ObjectId 经常也会被拿来当做分布式 ID 的解决方案。

MongoDB ObjectId 一共需要 12 个字节存储：

MongoDB 方案的优缺点：UUID

UUID 是 Universally Unique Identifier（通用唯一标识符） 的缩写。UUID 包含 32 个 16 进制数字（8-4-4-4-12）。

JDK 就提供了现成的生成 UUID 的方法，一行代码就行了。

RFC 4122[4] 中关于 UUID 的示例是这样的：

我们这里重点关注一下这个 Version(版本)，不同的版本对应的 UUID 的生成规则是不同的。

5 种不同的 Version(版本)值分别对应的含义（参考维基百科对于 UUID 的介绍[5]）：

下面是 Version 1 版本下生成的 UUID 的示例：

JDK 中通过 的 方法生成的 UUID 的版本默认为 4。

另外，Variant(变体)也有 4 种不同的值，这种值分别对应不同的含义。这里就不介绍了，貌似平时也不怎么需要关注。

需要用到的时候，去看看维基百科对于 UUID 的 Variant(变体) 相关的介绍即可。

从上面的介绍中可以看出，UUID 可以保证唯一性，因为其生成规则包括 MAC 地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，计算机基于这些规则生成的 UUID 是肯定不会重复的。

虽然，UUID 可以做到全局唯一性，但是，我们一般很少会使用它。

比如使用 UUID 作为 MySQL 数据库主键的时候就非常不合适：

最后，我们再简单分析一下 UUID 的优缺点 （面试的时候可能会被问到的哦！） :Snowflake(雪花算法)

Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 由 64 bit 的二进制数字组成，这 64bit 的二进制被分成了几部分，每一部分存储的数据都有特定的含义：

在实际项目中，我们一般也会对 Snowflake 算法进行改造，最常见的就是在 Snowflake 算法生成的 ID 中加入业务类型信息。

我们再来看看 Snowflake 算法的优缺点：

如果你想要使用 Snowflake 算法的话，一般不需要你自己再造轮子。有很多基于 Snowflake 算法的开源实现比如美团 的 Leaf、百度的 UidGenerator（后面会提到），并且这些开源实现对原有的 Snowflake 算法进行了优化，性能更优秀，还解决了 Snowflake 算法的时间回拨问题和依赖机器 ID 的问题。

并且，Seata 还提出了“改良版雪花算法”，针对原版雪花算法进行了一定的优化改良，解决了时间回拨问题，大幅提高的 QPS。具体介绍和改进原理，可以参考下面这两篇文章：UidGenerator(百度)

UidGenerator[10] 是百度开源的一款基于 Snowflake(雪花算法)的唯一 ID 生成器。

不过，UidGenerator 对 Snowflake(雪花算法)进行了改进，生成的唯一 ID 组成如下：

可以看出，和原始 Snowflake(雪花算法)生成的唯一 ID 的组成不太一样。并且，上面这些参数我们都可以自定义。

UidGenerator 官方文档中的介绍如下：

自 18 年后，UidGenerator 就基本没有再维护了，我这里也不过多介绍。想要进一步了解的朋友，可以看看 UidGenerator 的官方介绍[11]。Leaf(美团)

Leaf[12] 是美团开源的一个分布式 ID 解决方案 。这个项目的名字 Leaf（树叶） 起源于德国哲学家、数学家莱布尼茨的一句话：“There are no two identical leaves in the world”（世界上没有两片相同的树叶） 。这名字起得真心挺不错的，有点文艺青年那味了！

Leaf 提供了 号段模式 和 Snowflake(雪花算法) 这两种模式来生成分布式 ID。并且，它支持双号段，还解决了雪花 ID 系统时钟回拨问题。不过，时钟问题的解决需要弱依赖于 Zookeeper（使用 Zookeeper 作为注册中心，通过在特定路径下读取和创建子节点来管理 workId） 。

Leaf 的诞生主要是为了解决美团各个业务线生成分布式 ID 的方法多种多样以及不可靠的问题。

Leaf 对原有的号段模式进行改进，比如它这里增加了双号段避免获取 DB 在获取号段的时候阻塞请求获取 ID 的线程。简单来说，就是我一个号段还没用完之前，我自己就主动提前去获取下一个号段（图片来自于美团官方文章：《Leaf——美团点评分布式 ID 生成系统》[13]）。

根据项目 README 介绍，在 4C8G VM 基础上，通过公司 RPC 方式调用，QPS 压测结果近 5w/s，TP999 1ms。Tinyid(滴滴)

Tinyid[14] 是滴滴开源的一款基于数据库号段模式的唯一 ID 生成器。

数据库号段模式的原理我们在上面已经介绍过了。Tinyid 有哪些亮点呢？

为了搞清楚这个问题，我们先来看看基于数据库号段模式的简单架构方案。（图片来自于 Tinyid 的官方 wiki:《Tinyid 原理介绍》[15]）

在这种架构模式下，我们通过 HTTP 请求向发号器服务申请唯一 ID。负载均衡 router 会把我们的请求送往其中的一台 tinyid-server。

这种方案有什么问题呢？在我看来（Tinyid 官方 wiki 也有介绍到），主要由下面这 2 个问题：

除此之外，HTTP 调用也存在网络开销。

Tinyid 的原理比较简单，其架构如下图所示：

相比于基于数据库号段模式的简单架构方案，Tinyid 方案主要做了下面这些优化：

Tinyid 的优缺点这里就不分析了，结合数据库号段模式的优缺点和 Tinyid 的原理就能知道。IdGenerator(个人)

和 UidGenerator、Leaf 一样，IdGenerator[16] 也是一款基于 Snowflake(雪花算法)的唯一 ID 生成器。

IdGenerator 有如下特点：

IdGenerator 生成的唯一 ID 组成如下：

Java 语言使用示例：。

通过这篇文章，我基本上已经把最常见的分布式 ID 生成方案都总结了一波。

除了上面介绍的方式之外，像 ZooKeeper 这类中间件也可以帮助我们生成唯一 ID。没有银弹，一定要结合实际项目来选择最适合自己的方案。

不过，本文主要介绍的是分布式 ID 的理论知识。在实际的面试中，面试官可能会结合具体的业务场景来考察你对分布式 ID 的设计，你可以参考这篇文章：分布式 ID 设计指南[17]（对于实际工作中分布式 ID 的设计也非常有帮助）。[1]

Tinyid: %E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D[2]

Codis: [3]

Redis 持久化机制详解: [4]

RFC 4122: [5]

维基百科对于 UUID 的介绍: 通用唯一识别码[6]

随机性: 随机性[7]

伪随机性: 伪随机性[8]

Seata 基于改良版雪花算法的分布式 UUID 生成器分析: https://seata.io/zh-cn/blog/seata-analysis-UUID-generator.html[9]

在开源项目中看到一个改良版的雪花算法，现在它是你的了。: https://www.cnblogs.com/thisiswhy/p/17611163.html[10]

UidGenerator: [11]

UidGenerator 的官方介绍: /blob/master/README.zh_cn.md[12]

Leaf: [13]

《Leaf——美团点评分布式 ID 生成系统》: [14]

Tinyid: [15]

《Tinyid 原理介绍》: %E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D[16]

IdGenerator: [17]

分布式 ID 设计指南: