【业务功能篇73】分布式ID解决方案

这篇具有很好参考价值的文章主要介绍了【业务功能篇73】分布式ID解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

业界实现方案

1. 基于UUID
2. 基于DB数据库多种模式(自增主键、segment)
3. 基于Redis
4. 基于ZK、ETCD
5. 基于SnowFlake
6. 美团Leaf(DB-Segmentzk+SnowFlake)
7. 百度uid-generator()

1.基于UUID生成唯一ID

UUID:
UUID长度128bit3216进制字符,占用存储空间多,且生成的ID是无序的;

对于InnoDB这种聚集主键类型的引擎来说,数据会按照主键进行排序,由于UUID的无序性,InnoDB会产生巨大的IO压力,此时不适合使用UUID做物理主键,可以把它作为逻辑主键,物理主键依然使用自增ID

组成部分:

为了保证UUID的唯一性,规范定义了包括网卡MAC地址,时间戳,名字空间,随机或伪随机数,时序等元素.

优点

性能非常高:本地生成,没有网络消耗

缺点

不易于存储:UUID太长,16字节128位,通常以36长度的字符串表示,很多场景不适用

信息不安全:基于MAC地址生成UUID的算法可能会造成MAC地址泄露,这个漏洞曾被用于寻找梅丽莎病毒的制作者位置

ID作为主键时在特定的环境会存在一些问题,比如做DB主键的场景下,UUID就非常不适用

UUID生成策略 

UUID Version 1:基于时间的UUID

基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址,这个版本的UUID可以保证在全球范围的唯一性。但与此同时,使用MAC地址会带来安全性问题,这就是这个版本UUID受到批评的地方。如果应用只是在局域网中使用,也可以使用退化的算法,以IP地址来代替MAC地址--Java的UUID往往是这样实现的(当然也考虑了获取MAC的难度

UUID Version 2:DCE安全的UUID

DCE(Distributed Computing Environment)安全的UUID和基于时间的UUID算法相同,但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。

UUID Version 3:基于名字的UUID(MD5)

基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了:相同名字空间中不同名字生成的UUID的唯一性;不同名字空间中的UUID的唯一性;相同名字空间中相同名字的UUID重复生成是相同的。

UUID Version 4:随机UUID

根据随机数,或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的,但随机的东西就像是买彩票:你指望它发财是不可能的,但狗屎运通常会在不经意中到来。

UUID Version 5:基于名字的UUID(SHA1)

和版本3的UUID算法类似,只是散列值计算使用SHA1(Secure Hash Algorithm 1)算法

 

UUID应用

UUID Version 1:基于时间的UUID

从UUID的不同版本可以看出

Version 1/2适合应用于分布式计算环境下,具有高度的唯一性
Version 3/5适合于一定范围内名字唯一,且需要或可能会重复生成UUID的环境下
至于Version 4,建议是最好不用(虽然它是最简单最方便的)
通常我们建议使用UUID来标识对象或持久化数据,但以下情况最好不使用UUID:
映射类型的对象。比如只有代码及名称的代码表。
人工维护的非系统生成对象。比如系统中的部分基础数据。
对于具有名称不可重复的自然特性的对象,最好使用Version 3/5的UUID。比如系统中的用户。如果用户的UUID是Version 1的,如果你不小心删除了再重建用户,你会发现人还是那个人,用户已经不是那个用户了。(虽然标记为删除状态也是一种解决方案,但会带来实现上的复杂性。

【业务功能篇73】分布式ID解决方案,Spring boot,分布式,Java,分布式,分布式ID,spring boot 

 文章来源地址https://www.toymoban.com/news/detail-663337.html

2.基于DB数据库多种模式(自增主键、segment)

基于DB的自增主键方案 

实现原理:

基于MySQL,最简单的方法是使用auto_increment 来生成全局唯一递增ID,但最致命的问题是在高并发情况下,数据库压力大,DB单点存在宕机风险

优点:

实现简单、基于数据库底层机制

缺点:

高并发情况下,数据库压力大,DB单点存在宕机风险

 【业务功能篇73】分布式ID解决方案,Spring boot,分布式,Java,分布式,分布式ID,spring boot

 

基于DB多主模式方案

在分布式系统中我们可以多部署几台机器,

每台机器设置不同的初始值,且步长和机器数相等。

比如有两台机器。设置步长step为2,

TicketServer1的初始值为1(1,3,5,7,9,11…)、

TicketServer2的初始值为2(2,4,6,8,10…)。

这是Flickr团队在2010年撰文介绍的一种主键生成策略

(Ticket Servers: Distributed Unique Primary Keys on the Cheap )

如下所示,为了实现上述方案分别设置两台机器对应的参数,

TicketServer1从1开始发号,

TicketServer2从2开始发号,

两台机器每次发号之后都递增2

 

基于DB号段实现方案

实现原理:

每次向db申请一个号段,加载到内存中,然后采用自增的方式来生成id,这个号段用完后,再次向db申请一个新的号段,这样对db的压力就减轻了很多,同时内存中直接生成id。向数据库申请新号段,对max_id字段做一次update操作,update max_id= max_id + step,update成功则说明新号段获取成功,新的号段范围是(max_id ,max_id +step]。

优点:

利用了缓存,减轻DB压力,性能提升

缺点:

依然存在DB模式下的性能瓶颈,ID最大值的限制

 

3.基于Redis实现分布式ID 

  • 因为Redis是单线程的,所以天然没有资源争用问题,可以采用 incr 指令,实现ID的原子性自增
  • 但是因为Redis的数据备份-RDB,会存在漏掉数据的可能,所以理论上存在已使用的ID再次被使用,所以备份方式可以加上AOF方式,这样的话性能会有所损耗

 

4.基于Zookeeper实现分布式ID

原理:
利用zookeeper中的顺序节点的特性,制作分布式的序列号生成器(ID生成器)

5.基于ETCD实现分布式ID 

原理:
每个tx事务有唯一事务ID,在etcd中叫做main ID,全局递增不重复。

一个tx可以包含多个修改操作(putdelete),每一个操作叫做一个revision(修订),共享同一个main ID

一个tx内连续的多个修改操作会被从0递增编号,这个编号叫做sub ID

每个revision由(main IDsub ID)唯一标识。

6.美团Leaf-基于ZK的SnowFlake算法 

Leaf-snowflake方案完全沿用snowflake方案的bit位设计.

即是“1+41+10+12”的方式组装ID号。

对于workerID的分配,当服务集群数量较小的情况下,完全可以手动配置。

Leaf服务规模较大,动手配置成本太高。所以使用Zookeeper持久顺序节点的特性

自动对snowflake节点配置wokerID

【业务功能篇73】分布式ID解决方案,Spring boot,分布式,Java,分布式,分布式ID,spring boot

 

7.百度uid-generator分布式ID生成器

UidGeneratorJava实现的, 基于Snowflake算法的唯一ID生成器

UidGenerator以组件形式工作在应用项目中, 支持自定义workerId位数和初始化策略,

从而适用于docker等虚拟化环境下实例自动重启、漂移等场景

 在实现上, UidGenerator通过借用未来时间来解决sequence天然存在的并发限制;

采用RingBuffer来缓存已生成的UID, 并行化UID的生产和消费, 同时对CacheLine补齐

避免了由RingBuffer带来的硬件级「伪共享」问题. 最终单机QPS可达600万。

其实现原理和雪花算法并无二致,自定义号段,并且采用RingBuffer作为缓冲

从而提升性能。详见官网地址

https://github.com/baidu/uidgenerator/blob/master/README.zh_cn.md

 

到了这里,关于【业务功能篇73】分布式ID解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • 【业务功能100】补充代码【业务功能88】微服务-springcloud-分布式锁-redis-redisson-springcache

    采用redisson做分布式锁,完成数据的查询接口功能getCatelog2JSONRedis 原先从mysql数据库查询的效率较低,现在将部分固定数据展示比如页面的树形栏目信息等,存储到 redis缓存 ,然后基于分布式集群,需要结合本地锁(synchronized )与分布式锁(redissonClient.getLock(“catelog2JSON-lock”

    2024年02月09日
    浏览(46)
  • 分布式id解决方法--雪花算法

    uuid,jdk自带,但是数据库性能差,32位呀。 mysql数据库主键越短越好,B+tree产生节点分裂,大大降低数据库性能,所以uuid不建议。 redis的自增,但是要配置维护redis集群,就为了一个id,还要引入一套redis。费事,成本高。 如果有序自增别人就知道你的业务量多少了。 分布式

    2024年02月04日
    浏览(44)
  • 【业务功能篇87】微服务-springcloud-本地缓存-redis-分布式缓存-缓存穿透-雪崩-击穿

      缓存的作用是减低对数据源的访问频率。从而提高我们系统的性能。 缓存的流程图 2.1 本地缓存   其实就是把缓存数据存储在内存中(Map String,Object ).在单体架构中肯定没有问题。 单体架构下的缓存处理 2.2 分布式缓存   在分布式环境下,我们原来的本地缓存就不是

    2024年02月10日
    浏览(56)
  • 分布式锁解决方案_Zookeeper实现分布式锁

    提示:这里可以添加系列文章的所有文章的目录,目录需要自己手动添加 分布式锁解决方案_Zookeeper实现分布式锁 提示:写完文章后,目录可以自动生成,如何生成可参考右边的帮助文档 提示:这里可以添加本文要记录的大概内容: Zookeeper 是一个开源的分布式协调服务,它

    2024年02月03日
    浏览(42)
  • 【分布式事务】Seata 开源的分布式事务解决方案

    Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。 阿里巴巴作为国内最早一批进行应用分布式(微服务化)改造的企业,很早就遇到微服务架构下

    2024年02月02日
    浏览(53)
  • 【业务功能篇96】微服务-springcloud-springboot-认证服务-登录注册功能-Auth2.0-分布式session

      通过最基础的登录操作来完成登录处理 登录页面处理 认证服务的处理 会员中心的认证逻辑 service中的具体认证处理   OAuth2.0是OAuth协议的延续版本,但不向前兼容OAuth 1.0(即完全废止了OAuth1.0)。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商

    2024年02月09日
    浏览(56)
  • 分布式锁解决方案

    由于分布式或者集群部署项目时,在某些业务场景下需保证资源的原子性、一致性和互斥性。 如果把房子比作资源,通俗的来讲,我无论在那个城市生活,这个房子我先租的,再没有退房的前提下,别人都不能用 目前最流行的解决方案 redisson 分布式锁 zookeeper 分布式锁 mav

    2024年02月12日
    浏览(44)
  • 分布式websocket解决方案

    websocket基础请自行学习,本文章是解决在分布式环境下websocket通讯问题。 在单体环境下,所有web客户端都是连接到某一个微服务上,这样消息都是到达统一服务端,并且也是由一个服务端进行响应,所以不会出现问题。 但是在分布式环境下,我们很容易发现,客户端连接的

    2024年02月13日
    浏览(41)
  • 【SpirngCloud】分布式事务解决方案

    1.1 CAP 理论 1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标: Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致 Availability(可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝 Partition tolerance(分区容

    2024年02月15日
    浏览(45)
  • Redis 分布式锁解决方案

    我们日常在电商网站购物时经常会遇到一些高并发的场景,例如电商 App 上经常出现的秒杀活动、限量优惠券抢购,还有我们去哪儿网的火车票抢票系统等,这些场景有一个共同特点就是访问量激增,虽然在系统设计时会通过限流、异步、排队等方式优化,但整体的并发还是

    2023年04月22日
    浏览(44)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包