请选择 进入手机版 | 继续访问电脑版

分布式ID问题及解决方案

[复制链接]
甜蜜的负担 发表于 2020-12-31 20:23:12 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
title: 分布式ID问题及管理方案
comments: false
toc: true
categories:


  • 分布式方案
    tags:
  • 分布式ID
  • 雪花算法
    date: 2020-12-30 21:28:30
  为什么需要分布式ID?
传统的ID生成方式一般使用数据库自增,这样有序且长度可控,但是在分布式情况里,往往因库表数据过大而需要分库、分表,这样继承使用自增主键就会出现主键辩论问题。一般需要一个单独的机制或服务来生成一套全局的ID,这样的ID也叫分布式ID。
分布式ID现在有哪些常用做法?分别有什么优缺点?



  • UUID
    优点:生成方式简朴,无需第三方服务,可移植性好。
    缺点:长度较长,无序ID,插入数据库用作主键性能不佳。
  • 数据库自增主键(单机/集群),其他服务每次查询此最新值。
    优点:获取简朴,有序ID;下次生成ID可预期。
    缺点:需要依赖数据库,可移植性差。集群情况下需要给每台设置步长,维护时大概需要停机。
  • 号段模式,每次数据库生存起止ID位置,客户端请求时拿到范围后本地维护,用尽后再拿新的号段
    优点:有序ID;性能较好;不强依赖数据库,自增下放至本机可自行维持一定时间;
    缺点:很难包管ID差别号段的时间先后顺序(A服务先拿号段,却较后用完号段);容易造成ID空洞;
  • Redis incr下令原子自增(和数据库自增雷同) 推荐使用
    优点:使用简朴;效率极高;有序ID;
    缺点: 引入了redis依赖;
    ​ 需要考虑自增ID长期化问题:
    ​ RDB模式下快照未来得及长期化会出现ID重复。
    ​ AOF模式下不会ID重复,但会由于incr下令过多恢复数据时间过长。
  • 雪花算法 推荐使用
    优点:使用简朴;效率极高;有序ID;可移植性强;
    缺点:生成ID依赖本地时钟,如果时钟更正或倒退,会导致雪花算法拒绝生成ID;
雪花算法原理图:


常见雪花算法改造

百度(uid-generator)

uid-generator是由百度技能部开辟,项目GitHub地址 github/uid-generator
uid-generator是基于Snowflake算法实现的,与原始的snowflake算法差别在于,uid-generator支持自界说时间戳、工作机器ID和 序列号 等各部门的位数,而且uid-generator中接纳用户自界说workId的生成策略。
uid-generator需要与数据库共同使用,需要新增一个WORKER_NODE表。当应用启动时会向数据库表中去插入一条数据,插入乐成后返回的自增ID就是该机器的workId数据由host,port组成。
对于uid-generator ID组成结构:workId,占用了22个bit位,时间占用了28个bit位,序列化占用了13个bit位,需要注意的是,和原始的snowflake不太一样,时间的单元是秒,而不是毫秒,workId也不一样,而且同一应用每次重启就会消费一个workId。
美团(Leaf)

Leaf由美团开辟,github地址:github/Leaf
Leaf同时支持号段模式和snowflake算法模式,可以切换使用。
滴滴(Tinyid)

Tinyid由滴滴开辟,Github地址:github/tinyid
Tinyid是基于号段模式原理实现的与Leaf如出一辙,每个服务获取一个号段(1000,2000]、(2000,3000]、(3000,4000]
Tinyid提供http和tinyid-client两种方式接入。

来源:https://blog.csdn.net/ksisn/article/details/112000155
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )