介绍下分布式ID的技术实现及应用场景

什么是分布式ID

分布式ID是指在分布式系统中生成的特定范围内唯一的标识符,如订单号、商品ID、链路追踪TraceID。

随着业务发展,对分布式ID的要求越来越高,其中最基本的要求如下

  • 全局唯一:在任何节点、任何时间生成的ID都必须是唯一的;
  • 高性能:分布式ID的生成速度要快,对本地资源消耗小;
  • 高可用:生成分布式ID的服务要保证可用性接近于100%;
  • 方便易用:拿来即用,方便业务快速接入。

有哪些技术实现

1、数据库自增ID

原理 :基于数据库的auto_increment实现ID自增;

优点

  • 实现简单;
  • ID单调自增。

缺点

  • 性能较差,不适合高并发场景。

适用场景

  • 小型分布式系统;
  • 要求ID连续自增。

2、Redis自增

原理 :利用Redis的INCR命令生成自增ID。

优点

  • 简单高效,适合小规模分布式系统。

缺点

  • 依赖Redis,存在单点风险(可通过Redis集群缓解)。
  • 扩展性有限。

适用场景:对性能要求高且规模较小的场景(如分布式锁的唯一标识)

3、UUID

原理 :UUID,即通用识别码,是基于时间戳、MAC地址、随机数等生成128位的字符串(如550e8400-e29b-41d4-a716-446655440000)。

优点

  • 简单易用,无需协调;
  • 唯一性极高。

缺点

  • 无序,导致数据库索引效率低;
  • 长度较长(16字节),存储和传输开销大。

适用场景:对唯一性要求高,但对有序性和性能要求不高的场景(如临时文件命名)。

4、号段模式

**原理:**预先分配一组连续的号段(如10000~20000)给某个节点,节点预先拉取,在分配ID时 优先判断本地号段是否消耗完,如果消耗完的话,再从数据库中获取下一个号段。

优点

  • 网络开销大幅减少;
  • 无需处理时钟回拨、机器ID冲突等问题;
  • 生成的ID是连续的,适合数据库索引优化。

缺点

  • ID可能不连续;
  • 步长设置过短的话,可能会导致频繁请求数据库获取新号段,造成服务器压力。

适用场景

  • 高并发场景,如秒杀系统。

5、雪花算法

原理:由Twitter提出,将64位ID分为以下部分:

  • 1位符号位(始终为0)。
  • 41位时间戳(毫秒级,可用约69年)。
  • 10位工作机器ID(5位数据中心ID + 5位机器ID)。
  • 12位序列号(每毫秒可生成4096个ID)。

需要注意的是,这里的工作中心ID需要预先分配,作用是区分不同的服务节点。

优点

  • 高性能(本地生成,无需网络请求)。
  • 趋势递增,适合数据库索引。
  • 可扩展性强(通过调整机器ID位数)。

缺点

  • 依赖系统时钟,时钟回拨可能导致ID重复。
  • 机器ID需要预先分配(可通过配置或ZooKeeper动态分配)。

适用场景:大多数分布式系统(如订单ID、日志ID等)。

6、TinyID

**原理:**基于号段模式实现,不过支持多数据库模式,实现方式是一个主节点只生成偶数、另一个生成奇数;

优点

  • 适用于大多数分布式系统;
  • 多数据库支持:提高系统的可用性。

缺点

  • ID可能不连续;

根据业务场景选型

https://mp.weixin.qq.com/s/bFDLb6U6EgI-DvCdLTq_QA

相关推荐
冷崖1 天前
消息队列-kafka(一)
分布式·kafka
不光头强1 天前
kafka学习要点
分布式·学习·kafka
難釋懷1 天前
分布式锁-redission可重入锁原理
分布式
珠海西格1 天前
远动通信装置为何是电网安全运行的“神经中枢”?
大数据·服务器·网络·数据库·分布式·安全·区块链
CTO Plus技术服务中1 天前
分布式存储HBase开发与运维教程
运维·分布式·hbase
飞乐鸟1 天前
Github 16.8k Star!推荐一款开源的高性能分布式对象存储系统!
分布式·开源·github
panzer_maus1 天前
分布式锁的概念
分布式
Lansonli1 天前
大数据Spark(七十九):Action行动算子countByKey和countByValue使用案例
大数据·分布式·spark
少许极端1 天前
Redis入门指南(八):从零到分布式缓存-集群机制、缓存机制、分布式锁
redis·分布式·缓存·分布式锁
珠海西格2 天前
“主动预防” vs “事后补救”:分布式光伏防逆流技术的代际革命,西格电力给出标准答案
大数据·运维·服务器·分布式·云计算·能源