在一些超大型的系统中的唯一ID是如何生成的？比如Twitter的Status Id、微博的id等，一般有多种解决方案，这篇文章说明的比较详细：

原文：
🔗 twitter.com/Franc0Fernand0/status/1543235086266634241
🧵 http://t.cn/A6aJwJyr

原作者Franco Fernando 🍀 （@ Franc0Fernand0），以下内容为转译：
--------

许多大规模系统的后端需要生成唯一的ID。一些常见的解决方案是：
1. UUIDs
2.数据库生成的ID
3.服务生成的雪花IDs

这些方案是如何工作和区别的？参考图2

在单个节点上生成唯一的标识符并不是一件难事。一些简单的策略可以是：
1.使用一个递增的ID
2.使用一个获得一天中的时间的函数

这些策略在分布式环境中会失败，因为可能会产生重复的ID。

分布式系统中广泛使用的解决方案是通用唯一标识符（UUIDs）。

UUIDs是128位的数字，可以在应用层面以标准方式生成。

它们通常由几个部分组成，如时间、节点的MAC地址或MD5哈希值。

UUIDs的主要好处是：
1. 足够大的ID空间，几乎不可能重复
2. 唯一性，无需在分布式节点之间进行任何同步。

主要的缺点是：
1. 大尺寸较大（128位）。
2. 如果由不同的节点产生，则不是连续的ID。

第二种选择是在数据库层面而不是应用层面生成ID。许多数据库提供了ID自动递增功能。 因此，数据库服务器可以被用来生成唯一的ID。这种方法也被称为票据服务，Flickr就是用这种方式生成ID。

数据库生成ID的主要好处是：
- 应用程序代码变得更简单
- ID是有顺序的，而且尺寸很短

主要的缺点是：
- 从数据库中获取ID需要额外的消耗
- 数据库可能会成为一个瓶颈，出现故障会影响其他系统

最后一个问题可以用多个服务器来缓解。例如，服务器可以生成偶数ID，而另一个则生成奇数ID。

可以使用负载均衡技术来平衡服务器之间的负载，并处理停机时间。 显然，生成的ID在一段时间后会有一些漂移。

第三个选择是有一个专门的服务来生成雪花ID。

这种形式的独特ID是由Twitter引入的，然后也被Discord和Instagram采用。

其主要思想是将ID生成为多个字段的组合。

在最初的实现中，这些字段是：
- 41位的时间戳
- 10位工作者ID
- 12位序列号
- 1位保留给未来使用

一些观察结果：
- 分辨率为ms的时间戳可以在起始纪元后的70年内使用
- 工作者ID可以同时定义数据中心和机器ID。 它是由一个协调服务（Zookeper）分配的。
- 序列号支持每毫秒多达4096个唯一的ID

这种生成ID的方式有很多优点：
- 它是可用的，因为可以由1024台机器来实现
- 它是可扩展的，因为每台机器每毫秒可以生成4096个ID
- 由于时间戳在高阶位，所以ID是可以进行时间排序的。