九种分布式ID生成方式

分布式ID是应对大规模数据场景的关键,需要满足全局唯一、高性能、高可用、易接入等特性。常见的生成方式包括UUID、数据库自增、数据库集群、号段模式、Redis、SnowFlake算法等。每种方式都有其优缺点,适用于不同的业务场景。例如,SnowFlake算法能保证趋势递增且无冲突,适合大量并发的系统。在设计分布式ID时,还需要考虑信息安全、分片支持等因素。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

为什么要用分布式ID
在说分布式ID的具体实现之前,我们来简单分析一下为什么用分布式ID?分布式ID应该满足哪些特征?

1、什么是分布式ID
拿MySQL数据库举个栗子:

在我们业务数据量不大的时候,单库单表完全可以支撑现有业务,数据再大一点搞个MySQL主从同步读写分离也能对付。

但随着数据日渐增长,主从同步也扛不住了,就需要对数据库进行分库分表,但分库分表后需要有一个唯一ID来标识一条数据,数据库的自增ID显然不能满足需求;特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID

2、那么分布式ID需要满足哪些条件
全局唯一:必须保证ID是全局性唯一的,基本要求
高性能:高可用低延时,ID生成响应要块,否则反倒会成为业务瓶颈
高可用:对ID号生成系统的可用性要求极高,所以不能有单点故障
好接入:要秉着拿来即用的设计原则,在系统设计和实现上要尽可能的简单
趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来存储索引数据,在主键的选择上面我们应该尽量使用有序的主键保证写入性能
单调递增:保证下一个ID一定大于上一个ID,例如事务版本号、IM增量消息、排序等特殊需求
信息安全:如果ID是连续的,恶意用户的扒取工作就非常容易做了,直接按照顺序下载指定URL即可;如果是订单号就更危险了,竞争对手可以直接知道我们一天的单量。所以在一些应用场景下,会需要ID无规则、不规则
分片支持:可以控制ShardingId。比如某一个用户的文章要放在同一个分片内,这样查询效率高,修改也容易
二、 分布式ID有哪些生成方式
今天主要分析一下以下9种,分布式ID生成器方式以及优缺点:

基于UUID
基于数据库自增ID
基于数据库集群模式
基于数据库的号段模式
基于Redis模式
基于雪花算法(SnowFlake)
百度 (Uidgenerator)
美团(Leaf)
滴滴出品(TinyID)

转载地址:
https://zhanghaiyang.blog.youkuaiyun.com/article/details/104476003

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值