# 前言
很多事情一旦牵涉到分布式，问题就变得复杂了。

当我们的系统从一个单点，扩展成一群相互协作的节点时，生成一个简单的唯一ID，就需要思考很多。

例如接手一个老系统，它的订单ID用的是数据库自增。一开始跑得好好的，直到有一天，业务说要分库分表。这就麻烦了，每个库都自己从1开始数，全网到处是重复的订单号。或者，我们设计一个新的社交动态Feeds流，如果ID不是大体有序的，插入数据库时就会产生大量的页分裂，磁盘I/O飙升，性能一下子就变得垃圾了。

那咋搞？

# 方案一：UUID
大家都肯定听说过uuid

它的好处很明显：本地生成，没有协调开销，理论上几乎不可能重复。用起来随手可得。
```
# 在任何地方，任何时间
import uuid
unique_label = uuid.uuid4()  # 比如：9a72f5a0-6e1c-4b3d-8f21-3c9e7b1ad4c1
```

但是问题也很明显。太`自由`了。

36位的字符，作为数据库主键时，在索引树里占的地方大，对比起来慢。

更关键的是，它完全无序。这意味着新的记录可能插入到表的任何位置，对于写密集型的表，性能会出现瓶颈。
![Gemini_Generated_Image_ppag20ppag20ppag.png](https://developer.qcloudimg.com/http-save/yehe-1367556/c8445892b0f31b0d3866d7ec7626e1ed.png)

# 方案二：数据库自增ID
当我们意识到需要`有序`时，很自然就会想到设立一个“中心”。

- **数据库自增**：这是最朴素的权威。但它一旦单点故障，整个系统就瘫痪了。为了给它减负，我们可以使用“号段模式”——每次去中心那里领一个号码范围（比如10000-20000），本地慢慢发。**美团Leaf** 把这个思路做到了极致，通过双Buffer异步预取，让本地几乎永远有号可用，把对数据库的冲击降到最低。
- **Redis INCR**：这是一个更快的方案。但引入它，就意味着我们的系统架构里又多了一个需要维护、需要保证高可用的核心组件。
- **Zookeeper顺序节点**：通过一致性协议保证了最强的秩序，但为此付出的性能代价，需要我们好好考虑一下。

这类方案的共性在于，我们把“唯一且有序”这个难题，转移给了一个更专业的系统。
![古典议事厅登记官.png](https://developer.qcloudimg.com/http-save/yehe-1367556/5831d4e23eea0ef862c99008e0bf9aa7.png)
我们的复杂度转移了，但依赖产生了。在分布式系统中，这种依赖关系是需要仔细权衡的。

# 方案三：雪花Snowflake算法

当系统规模大到任何一个中心都难以承受时，我们不得不走向`自治`。

Snowflake算法是这种思想的典型例子：**让每个节点，按照一套共同的规则，自己生成ID**。

这个规则，就是把一个64位的数字，划分成几个意义明确的区间：时间戳、机器ID、序列号。
意思就是：**“这是2023年X月Y日Z毫秒，在A号机器上生成的第B个ID”**。

它解决了有序和唯一的问题，但引入了一个更底层的依赖：**机器时钟的同步**。

想象一下，机器上时钟突然倒退了十分钟，而机器还在按原来的节奏发号，重复就发生了。

所以大家都拿出了自己的解决方案。

- **美团Leaf-snowflake**：在启动和运行时都死死盯着时钟（通过ZooKeeper对比其他机器的时间），一旦发现时间错乱且无法追回，就立刻拉响警报，宁可暂停服务也不发出重复的号。
- **百度UidGenerator (Cached模式)**：它换了一种思路，预先在内存里（RingBuffer）生产一大堆ID，并且自己维护一个逻辑时间戳来推进，从而在很大程度上“屏蔽”了物理时钟的细微回拨。
- **文内“多时间线”方案**：这个想法非常大胆，它承认时间可能会“开倒车”，那就为系统准备几条备用的时间线。当前的时间线发生倒流时，就切换到一条流速更慢的、尚未被污染的时间线上继续发号。
![蒸汽朋克齿轮机械世界.png](https://developer.qcloudimg.com/http-save/yehe-1367556/e5beb3ade9ebcb8b04d32ae2ef1540f8.png)
# 总结

没有一个选项是完美的。只能学会取舍。

我们需要考虑：

1. **对“有序性”的要求有多强？** 是绝对不能接受乱序（如金融交易），还是“趋势递增”就足够了（如社交动态）？
2. **我们预估的峰值生成速率是多少？** 每秒一千，一万，还是十万？这决定了方案能不能扛住压力。
3. **我们的系统容灾能力如何？** 能接受ID服务短暂不可用吗？还是要求五个9的可用性？
4. **团队的精力和技术储备偏向哪里？** 是更熟悉数据库运维，还是更能掌控ZooKeeper和时钟同步这些底层问题？
5. **是否有安全或隐私顾虑？** 比如，ID里是否绝对不能泄露机器ID、生成时间等信息？

大多数情况下，一个常见的演进路径是这样的：

早期用**数据库号段**，简单够用；随着规模扩大，引入**Leaf-segment**这类优化过的号段服务；

当规模发展到需要彻底去中心化、且有能力组建专门的基础设施团队时，再基于**Snowflake**打造自己的发号体系，并承受与之相伴的运维复杂性。

当我们的系统从一个单点，扩展成一群相互协作的节点时，生成一个简单的唯一ID，就需要思考很多。

谈谈分布式唯一ID方案

十倍工程师

架构设计

数据库

后端

分布式系统唯一ID生成方案比较：UUID简单但无序，数据库自增依赖中心化，Snowflake算法去中心化但需时钟同步。根据业务需求选择方案，平衡有序性、性能和可用性，从数据库号段逐步演进到Snowflake体系。

容灾

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

谈谈分布式唯一ID方案-腾讯云开发者社区-腾讯云

谈谈分布式唯一ID方案

谈谈分布式唯一ID方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐