什么是分布式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可能不连续;