【设计】6种ID生成策略描述,优点 ,缺点 ,适用场景

   日期:2024-12-26    作者:maoxiangsy 移动:http://ljhr2012.riyuangf.com/mobile/quote/32806.html

自增Id是在设计表时将id字段的值设置为自增的形式,这样当插入一行数据时无
需指定id会自动根据前一字段的Id值+1进行填充 

主键自动增长,不用手工设值、数字型,占用空间小、检索非常有利、有顺序,不会重复。

并发性能不高,受限于数据库性能、不太适合重构的系统,因为涉及旧数据迁移容易Id冲突,还有
外键要考虑、新旧系统上线同时运行,数据涉及双写容易Id冲突。

在互联网公司,对于高并发业务,一般的表主键都是采用数据库自增,即使采用分库分表,也是
设置主键自增,原因是:一般表的主键不参与业务处理, 比较常见的设计方式是业务表加一个
业务唯一健,而且唯一健不能改变,其他业务表关联这个表的唯一键参与各种逻辑处理。例如
券表:券Id、券号----活动表:活动Id、活动code-----活动发送记录表: 
记录Id、mobile、活动code、券号

UUID是通用唯一标识码的缩写,集群全局唯一不会重复,UUID是基于当前时间、计
数器、机器的mac地址等数据计算生成的。

本地生成没有网络IO,性能好、全局唯一不重复、使用简单不用引入中间件。

UUID占用16个字符,空间占用较多,如果是千万级别甚至亿级别特别费空间、不
是递增的而且无序、随机写入索引性能下降。

对表空间没太多限制、重构类系统、UUID不作为查询字段的非高并发系统、集群
部署的中间件唯一Id。

Redis计数器,原子性自增,调用incr、incrBy方法。

并发性能高,有顺序、生成Id格式可以自定义,例如前缀+yyyyMMdd+5位自增。

使用场景有限、因为自增,数据量容易被猜到,不安全、引入中间件、redis集群
部署需要保证高可用成本高。

生成Id要求自增、高性能、适合运营管理后台唯一Id生成,例如活动编号。

Twitter开源的分布式ID生成算法,主要是由64bit的long型生成的全局ID,引入
了时间戳和ID保持自增的属性,组成结构如下
1bit(1:负数,0:正数)
41bit(时间戳
5bit(表示机房Id,2^5个机房-32个机房
5bit(表示机器Id,2^5个机器-32个机器
12bit(序列号, 这个是用来记录同一个毫秒内产生的不同id,4096

不依赖外部组件、性能好、按时间递增。

缺点

机房+机器设置不合理高并发下可能会重复(应用启动机房Id、机器ID作为启动参
数传递保证唯一)、有时钟回拨的坑。
例如:729786672057983180、729786672057983181

互联网高并发系统

UidGenerator是Java实现的, 基于Snowflake算法的唯一ID生成器。
UidGenerator以组件形式工作在应用项目中, 支持自定义workerId位数和初始化策略, 
从而适用于k8s环境下实例自动重启、IP漂移等场景。

在实现上, UidGenerator通过借用未来时间来解决sequence天然存在的并发限制; 
采用RingBuffer来缓存已生成的Uid, 并行化Uid的生产和消费, 同时对CacheLine补齐
避免RingBuffer带来的伪共享问题. 最终单机QPS可达600万。

非高并发业务不适合

互联网高并发系统

什么是Leaf

全局唯一,绝对不会出现重复的ID,且ID整体趋势递增。
高可用,服务完全基于分布式架构,即使MySQL宕机,也能容忍一段时间的数据库不可用。
高并发低延时,在CentOS 4C8G的虚拟机上,远程调用QPS可达5W+,TP99在1ms内。
接入简单,直接通过公司RPC服务或者HTTP调用即可接入。

leaf是叶子的意思,使用的Leaf是美团公司开源的一个分布式序列号(id)生成系统

我们可以在Github网站上下载项目直接使用

更多介绍可以参考官方信息

官方介绍地址:Leaf——美团点评分布式ID生成系统 - 美团技术团队

github:GitHub - Meituan-Dianping/Leaf: Distributed ID Generate Service

为什么需要Leaf

上面的图片中

是一个实际开发中常见的读写分离的数据库部署格式

专门进行数据更新(写)的有两个数据库节点

它们同时新增数据可能产生相同的自增列id

一旦生成相同的id,数据同步就会有问题

会产生id冲突,甚至引发异常

我们为了在这种多数据库节点的环境下能够产生唯一id

可以使用Leaf来生成

Leaf的工作原理

Leaf底层支持通过"雪花算法"生成不同id

我们使用的是单纯的序列

要想使用,需要事先设置好leaf的起始值和缓存id数

举例,从1000开始缓存500

也就是从id1000~1499这些值,都会保存在Leaf的内存中,当有服务需要时,直接取出下一个值

取出过的值不会再次生成,当缓存的数据取完时,会往后再缓存500个,从1500-1999

leaf要想设置起始值和缓存数

需要给leaf创建一个指定格式的数据库表

运行过程中会从数据库表获取信息

我们当前的信息保存在leafdb.leaf_alloc表中

leafdb.leaf_alloc代码

 
 

支持号段模式和雪花算法:
号段模式依赖于数据库,但是区别于数据库主键自增的模式。假设100为一个号段
100,200,300,每取一次可以获得100个Id ,性能显著提高。

非高并发业务不适合

互联网高并发系统


特别提示:本信息由相关用户自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。


举报收藏 0评论 0
0相关评论
相关最新动态
推荐最新动态
点击排行
{
网站首页  |  关于我们  |  联系方式  |  使用协议  |  隐私政策  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  网站留言  |  RSS订阅  |  违规举报  |  鄂ICP备2020018471号