分布式id的概述与实现

这篇具有很好参考价值的文章主要介绍了分布式id的概述与实现。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。


前言

随着业务的增长,数据表可能要占用很大的物理存储空间,为了解决该问题,后期使用数据库分片技术。将一个数据库进行拆分,通过数据库中间件连接。如果数据库中该表选用ID自增策略,则可能产生重复的ID,此时应该使用分布式ID生成策略来生成ID。


提示:以下是本篇文章正文内容

一、分布式id技术选型

  • redis,优势是(INCR)生成一个全局连续递增的数字类型主键,劣势是增加了一个外部组件的依赖,redis不可用,则整个数据库将无法插入
  • UUID,优势是全局唯一,mysql也有UUID实现,劣势是36个字符组成,占用空间大
  • snowflake(雪花)算法,优势是全局唯一,数字类型,存储成本低,机器规模大于1024台无法支持。

二、雪花算法

  • snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是0。
    分布式id的概述与实现,分布式

三、在项目中集成雪花算法

mybatis-plus已经集成了雪花算法,完成以下两步即可在项目中集成雪花算法:文章来源地址https://www.toymoban.com/news/detail-732854.html

  • 在实体类中的id上加入如下配置,指定类型为id_worker
@TableId(value = "id",type = IdType.ID_WORKER)
private Long id;
  • 在application.yml文件中配置数据中心id和机器id
mybatis-plus:
  mapper-locations: classpath*:mapper/*.xml
  type-aliases-package: com.model.pojos
  global-config:
    datacenter-id: 1
    workerId: 1

到了这里,关于分布式id的概述与实现的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【分布式技术专题】「分布式ID系列」百度开源的分布式高性能的唯一ID生成器UidGenerator

    UidGenerator是什么 UidGenerator是百度开源的一款分布式高性能的唯一ID生成器,更详细的情况可以查看官网集成文档 uid-generator是基于Twitter开源的snowflake算法实现的一款唯一主键生成器(数据库表的主键要求全局唯一是相当重要的)。要求java8及以上版本。 snowflake算法 Snowflake算法描

    2024年02月04日
    浏览(49)
  • 分布式id实战

    目录 常用方式 特征 潜在问题 信息安全 高性能 UUID 雪花算法 数据库生成 美团Leaf方案 Leaf-segment 数据库方案 Leaf-snowflake 方案 uuid 雪花算法 数据库主键 全局唯一 趋势递增 信息安全 如果id连续递增, 容易被爬虫, 批量下载数据 如果订单id是连续递增, 容易被竞争对手推算出日交

    2024年02月21日
    浏览(36)
  • 分布式ID(2):雪花算法生成ID

    1 雪花算法简介 这种方案大致来说是一种以划分命名空间(UUID也算,由于比较常见,所以单独分析)来生成ID的一种算法,这种方案把64-bit分别划分成多段,分开来标示机器、时间等,比如在snowflake中的64-bit分别表示如下图(图片来自网络)所示: 41-bit的时间可以表示(1L

    2024年01月20日
    浏览(37)
  • 算法、语言混编、分布式锁与分布式ID、IO模型

    数据结构和算法是程序的基石。我们使用的所有数据类型就是一种数据结构(数据的组织形式),写的程序逻辑就是算法。 算法是指用来操作数据、解决程序问题的一组方法。 对于同一个问题,使用不同的算法,也许最终得到的结果是一样的,但在过程中消耗的资源(空间

    2024年02月08日
    浏览(35)
  • 架构设计-分布式ID

    1.不要用主键ID作为业务单号的唯一标识,因为一是数据同步麻烦,第二一旦业务数据扩张涉及到分库分表则数据维护麻烦,因为此时主键ID容易造成重复 。 2.对于有相似属性的业务ID如直播或者录播ID存储在业务表中的一个字段,一旦程序员哪天状态不好忘记区分类型,就很

    2024年02月03日
    浏览(77)
  • 分布式唯一ID实战

    UUID的标准形式包含32个16进制数字,以 “ - ” 进行分割,形式为 8-4-4-4-12的32个字符,实例 550e8400-e29b-41d4-a716-446655440000。 优点: - 性能高,本地生成,没有网络消耗 缺点: - 不易存储,长度太长,32个16进制数字,128位 - 不安全,会暴露MAC地址 - UUID作为MySQL主键,会导致索引

    2024年02月12日
    浏览(31)
  • 分布式ID系统设计(2)

    https://editor.csdn.net/md/?articleId=133988963 应用举例 mongoDB ObjectID 就是一个典型的实现。 以MySQL举例 利用给字段设置AUTO-INCREMENT来保证ID自增,每次业务使用SQL拿到MySQL的ID 这种方案的优缺点: 优点 1 简单。利用数据库实现 成本小,有专业的DBA维护 2 ID单调递增。用来实现一些对于ID有

    2024年02月06日
    浏览(34)
  • 76、分布式id生成方案

    1,当前日期和时间 时间戳 2,时钟序列。 计数器 3,全局唯一的IEEE机器识别号,如果有网卡,从网卡MAC地址获得,没有网卡以其他方式获得。 优点: 代码简单,性能好(本地生成,没有网络消耗),保证唯一(相对而言,重复概率极低可以忽略) 缺点: 每次生成的ID都是无序的,

    2024年02月16日
    浏览(35)
  • 分布式ID系统设计(1)

    我们姑且把它叫做id-server 。那么这么个id-server的设计和考虑需要什么 全局唯一:不能出现重复的id号 最基本要求。 趋势递增: 在innodb中使用的是聚集索引。B+Tree的pk最好是有序的 单调递增:保证下一个id一定要大于上一个id 安全:如果ID是连续的 被爬虫的可能性能就很大。有一些

    2024年02月08日
    浏览(38)
  • 分布式ID系统设计(3)

    第二集说了id-service-Segment-DB可以生成趋势递增的ID,但是ID号是可以计算的。不太适用于一些订单ID生成的场景。因为存在数据暴露的风险 比如我可以对比两天的订单ID号来大致计算出公司一天的订单量。这个有点危险。 所以我们需要id-serviceSnowFlake方案。 id-service-snowFlake完全沿

    2024年02月06日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包