唯一ID的设计在我们系统的开发中是非常重要的，几乎所有的系统设计都离不开ID编码，如电商订单编号、快递单号等。良好的ID编码设计能提高数据存储和检索的效率，便于分布式系统的部署。

常用分布式ID算法

这里我们对常用的几种ID编码方式进行整理和对比，以作抛砖引玉，相关算法对应不同编程语言的实现，网上都可以找到很多例子。

雪花算法

雪花算法（Snowflake），twitter公司内部分布式项目采用的ID生成算法，目前广受开发者的欢迎，所以这里做下简单介绍。

雪花算法ID的64位二进制结构如下：

Snowflake的64位二进制结构

• 第一段1位为未使用，永远固定为0。
• 第二段41位为毫秒级时间(41位的长度可以使用69年)。
• 第三段10位为WorkerId(10位的长度最多支持部署1024个节点）。
• 第四段12位为毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）。

业务中我们可以64位二进制转换成十进制长整型的形式。因为根据时间生成，所以它是有序的，数据检索性能高。

ID示例：27206497290486784

优点：

1、不依赖系统或者数据库。

2、性能好，稳定性高。

缺点：

1、时钟回拨：强依赖机器时间，如果机器上时钟修改回调，也有可能会导致主键重复的问题。

2、手动配置：WorkerId（机器ID）是需要部署时手动配置的，而且WorkerId不能重复，这在项目部署的时候需要特别注意。

UUID / GUID

UUID（Universally Unique Identifier）通用标识码，GUID（Globals Unique Identifiers）全球唯一标识符。UUID 是一种标准，GUID 是 UUID 的实现之一。UUID编码结构如下：

UUID格式结构

• 1~8位采用系统时间，在系统时间上精确到毫秒级保证时间上的唯一性。
• 9~16位采用底层的IP地址，在服务器集群中的惟一性。
• 17~24位采用当前对象的HashCode值，在一个内部对象上的惟一性。
• 25~32位采用调用方法的一个随机数，在一个对象内的毫秒级的唯一性。

ID示例：652b83c2-e18b-41d4-a266-55f63d12df0

优点：

• 降低全局节点的压力，使得主键生成速度较快。
• 跨服务器合并数据方便。

缺点：

• UUID占用16个字符，空间占用较多。
• 不是递增的有序数字，数据写入IO随机性大，因此检索效率会有所降低。

Redis自增

当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR 和 INCRBY 来实现。

优点：

• 依赖于数据库，灵活方便，且性能优于数据库。
• 数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

• 如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。
• 需要编码和配置的工作量比较大。

数据库的主键自增

简单易实现，比较常用的ID生成方式，利用数据库自身的主键自增功能实现。

优点：

• INT和BIGINT类型占用空间较小。
• 主键自动增长，IO写入连续性好。
• 数字类型查询速度优于字符串。

缺点：

• 并发性能不高，受限于数据库性能。
• 分库分表，需要改造，复杂。
• 自增有规律，会导致数据泄露。

其他分布式ID

1、滴滴 TinyID

Github地址：GitHub - didi/tinyid: ID Generator id生成器 分布式id生成系统，简单易用、高性能、高可用的id生成系统

2、百度 UidGenerator

Github地址：GitHub - baidu/uid-generator: UniqueID generator

3、美团 Leaf

Github地址：GitHub - Meituan-Dianping/Leaf: Distributed ID Generate Service

4、数据库集群模式

采用数据库集群的模式，对数据库自增ID进行扩充。

5、基于数据库的号段模式

为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 [1,1000] 代表1000个ID，具体的业务服务将本号段，等这批号段ID用完，再次向数据库申请新号段。

总结

以上就是常用的分布式全局唯一ID的解决方案，ID编码方式的选择需要根据数据存储空间的大小要求、数据检索效率高低的要求，还有是否易于系统移植的要求去作出选择，每一种编码方式都不完美，我们需要根据自身业务实际情况，去动态地选择调整。