分布式Id/框架/发号器一文介绍

已于 2024-05-19 19:59:42 修改
阅读量1.3k 收藏 28
点赞数 16
分类专栏： Java 文章标签： 分布式 java
于 2024-05-19 19:54:56 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010365335/article/details/137759499
版权

文章目录

一、分布式id介绍

1、什么是分布式id

业务需求中需要对各种数据使用id进行唯一标识。
分布式ID是在分布式系统下使用的唯一标识，它用于保证数据的一致性和唯一性。
在传统的单机环境下，可以使用自增主键或UUID来生成唯一的ID，但在分布式环境下，由于多个节点同时生成ID，可能会出现重复的情况。
因此，需要一种能够生成全局唯一ID的解决方案，这就是分布式ID。

2、分布式id的特点

  • 全局唯一：在分布式环境下无论是在哪个节点生成的ID，都必须是全局唯一的，不能出现重复的情况
  • 趋势递增：生成的分布式ID通常要求能够近似有序递增，有助于后续业务需求使用id记性排序。ID 的有序性可以提升数据库写入速度，如在数据库中使用B+Tree数据结构时，自增顺序写入的数据能够保持B+Tree的结构稳定，从而提高存取效率
  • 高可用性：分布式ID生成系统需要保证在任何时候都能正确生成ID，即使在某些节点故障的情况下，整个系统仍能保持正常运行
  • 高性能性：在分布式环境下，特别是在高并发场景下，分布式ID生成系统需要能够迅速、高效地生成ID，且对服务本身的本地资源消耗小，以满足业务需求。
  • 信息安全：分布式ID的生成过程需要保证安全，不能被恶意用户推测出下一个ID，以防止可能的攻击，比如获取订单号，获取下载链接等

二、UUid生成算法

1、JDK UUID

JDK提供了现成的UUID生成方式，如下代码所示，包含了32个16进制的数字，以-分为五段，8-4-4-4-12

UUID uuid = UUID.randomUUID();
//输出示例：5c89a67d-4541-42d1-85e9-807bd93f065b
System.out.println(uuid);

JDK的版本不同，生成UUID的规则也不同，实现方式参考文档：
从源码角度分析UUID的实现原理

  • 版本 1 : UUID 是根据时间和节点 ID（通常是 MAC 地址）生成；
  • 版本 2 : UUID 是根据标识符（通常是组或用户 ID）、时间和节点 ID 生成；
  • 版本 3、版本 5 : 通过散列（hashing）名字空间（namespace）标识符和名称生成；
  • 版本 4 : UUID 使用随机性open in new window或伪随机性open in new window生成

优点：生成速度快，简单易用，一行代码搞定，本地生成，没有网络损耗
缺点：

  1. 存储空间消耗大: UUID 是一个 128 位的字符串，相比于传统的 32 位或 64 位整数 ID，它占用了更多的存储空间。这可能会增加数据库和存储系统的负担
  2. 可读性差: UUID 的格式通常是一长串的字符，可读性差
  3. 无序: 基于时间的 UUID 虽然具有一定的有序性，但由于其包含了时间戳、机器 MAC 地址和随机数等多个部分，因此并不完全按照时间顺序排列。这可能对于某些需要按时间顺序处理数据的场景造成不便

2、Snowflake 雪花算法

![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/534cd2ef36584970a500025aa8f46281.png
Snowflake算法描述：指定机器 & 同一时刻 & 某一并发序列，是唯一的。据此可生成一个64 bits的唯一ID（long）。默认采用上图字节分配方式，除了sign：1bit序号位不可调整外，其他的标识都可以根据实际情况做些调整。

  • sign(1bit)：固定1bit符号标识，表示正式，业务中常用于标识生成的UID为正数
  • timestamp(41bit):用于表示时间戳，相对于某个时间基点的增量值，单位是毫秒，可以支持 (1L<<41)/1000L360024*365 ≈ 69年
  • datacenter id + worker id （10bit）：在分布式IDC环境下，一般用前5位标识机房id/大区id，后五位表示机器id，用来区分不同的集群/机房的节点，这样可以表示32个IDC，每个IDC下面可以有32个机器
  • sequence(12bit):用来表示每毫秒下的并发序列，序列号为自增值，12个bit代表单台机器每毫秒能够生成2^12=4096个ID，理论上snowflake方案的QPS约为409.6w/s
  • 可支持单业务单大区重启 2^17-1=131071次

优点：生成速度比较快，毫秒数在高位，自增序列号在低位，整体ID是趋势递增的，业务需要时可以加上业务ID
缺点：强依赖机器时钟，如果机器上时钟回拨（即服务器上的时间突然倒退回之前的时间），进而导致发号重复或者服务会处于不可用状态

3、PearFlower 梨花算法

雪花算法的改进方法，目标：解决雪花算法的时间回拨问题，秒级时间戳回避毫秒级时间回拨问题；随机段号降低相同机器ID造成的影响
原理

  • 符号位：1位
  • 时间：31位，精确到秒级，可以用68年
  • 段号(批次号)：3位 每秒可分为8个段
  • 机器号：10位 最多支持1024台机器
  • sequence：19位 可表示:0–524287

优化点

  1. 经过调整，时间只对秒灵敏，成功回避了服务器间几百毫秒的时间误差引起的时间回拨问题；
  2. 若第59秒的8个段号没有用完，则当润秒来临时，还可继续使用
  3. 可设置一定的秒数（如3秒）内提前消费。比如第10秒的号码，在800毫秒用完了，可以继续使用第11秒的号码。这样，下1秒用的号码不是很多时，就可以借给上1秒使用。

参考：分布式全局唯一ID生成算法(改进的雪花算法——解决时钟回拨问题) https://blog.csdn.net/abckingaa/article/details/106460583

4、Mist 薄雾算法

在这里插入图片描述
原理

  • 第一段为最高位，占 1 位，保持为 0，使得值永远为正数；
  • 第二段放置自增数，占 47 位，自增数在高位能保证结果值呈递增态势，遂低位可以为所欲为；
  • 第三段放置随机因子一，占 8 位，上限数值 255，使结果值不可预测；
  • 第四段放置随机因子二，占 8 位，上限数值 255，使结果值不可预测；

优点：递增态势、不依赖数据库、高性能；不受时间回拨的影响

缺点：程序重启会造成按序递增数值回到初始值，要借助存储在程序重启时恢复自增序列。

三、常见发号器服务

1、数据库

1）自增

原理：利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增

  1. 建表：
CREATE TABLE `sequence_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `stub` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

创建一张序号表，stub字段无实际意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。

  1. SQL
BEGIN;
REPLACE INTO sequence_id (stub) VALUES ('stub');
SELECT LAST_INSERT_ID();
COMMIT;


DELETE FROM sequence_id WHERE id = LAST_INSERT_ID();

第一步：尝试把数据插入表中
第二步：如果主键或唯一索引的字段因出现重复数据而插入失败时，先从表中删除含有重复关键字的冲突行，然后再次尝试把数据插入表中。

优点

  1. 非常简单，利用现有数据库系统的功能实现，成本小，存储空间消耗小，有DBA专业维护
  2. ID号单调自增，可以实现一些对ID有特殊要求的业务

缺点

  1. 支持的并发量不大， 强依赖DB，当DB异常时整个系统不可用，属于致命问题，配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证，主从切换时的不一致可能会导致重复发号。
  2. 存在数据库单点问题，ID发号性能瓶颈限制在单台MySQL的读写性能 ，可以用数据库集群解决，不过增加了系统复杂度。如在分布式系统中每台机器设置不同的id初始值，且步长和机器数相等，不过系统维护困难，系统水平扩展比较困难，比如定义好了步长和机器台数之后，不容易扩展
  3. 数据库压力大，每次获取ID都得读写一次数据库，只能靠堆机器来提高性能
  4. ID没有具体的业务含义，而且存在安全问题，自增的订单ID存在规律，可以推测出业务数据，比如每天订单量等

2）号段模式

原理：
从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将使用本号段，生成1~1000的自增ID并加载到内存，从内存获取速度很快

  1. 建表
CREATE TABLE `sequence_id_generator` (
  `id` int(10) NOT NULL,
  `current_max_id` bigint(20) NOT NULL COMMENT '当前最大id',
  `step` int(10) NOT NULL COMMENT '号段的长度',
  `version` int(20) NOT NULL COMMENT '版本号',
  `biz_type`    int(20) NOT NULL COMMENT '业务类型',
   PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

biz_type ：代表不同业务类型
current_max_id：当前最大的可用id
step ：代表号段的长度
version ：是一个乐观锁，每次都更新version，保证并发时数据的正确性

current_max_id 字段和step字段主要用于获取批量 ID，获取的批量 id 为：current_max_id ~ current_max_id+step。

  1. 先新增一行数据
INSERT INTO `sequence_id_generator` (`id`, `current_max_id`, `step`, `version`, `biz_type`)
VALUES
 (1, 0, 100, 0, 101);
  1. 通过 SELECT 获取指定业务下的批量唯一 ID
UPDATE sequence_id_generator SET current_max_id = current_max_id +step, version=version+1 WHERE version = 0  AND `biz_type` = 101
SELECT `current_max_id`, `step`,`version` FROM `sequence_id_generator` where `biz_type` = 101

结果：id current_max_id step version biz_type
1 100 100 1 101

  • update current_max_id = current_max_id + step，update成功则说明新号段获取成功，新的号段范围是(current_max_id ,max_id +step]
  • update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX
  • 由于多业务端可能同时操作，所以采用版本号version乐观锁方式更新，这种分布式ID生成方式不强依赖于数据库，不会频繁的访问数据库，对数据库的压力小很多
  1. 不够用的话，更新之后重新 SELECT 即可。
    等这批号段ID用完，再次向数据库申请新号段，对current_max_id 字段做一次update操作

优点：比于数据库主键自增的方式，数据库的号段模式对于数据库的访问次数更少，数据库压力更小，存储消耗空间更小

缺点：跟自增模式类型，同样存在数据库单点问题、ID 没有具体业务含义、安全问题、

2、NoSQL

以使用Redis为主，原理就是利用redis的 incr命令实现ID的原子性自增。

127.0.0.1:6379> set seq_id 1     // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_id      // 增加1，并返回递增后的数值
(integer) 2

要考虑到redis持久化

最低0.47元/天 解锁文章
来聊聊大厂常用的分布式ID生成方案
Hi，我是sharkchili，CSDN Java领域博客专家，开源项目JavaGuide维护人员，我想写一些有意思的东西，希望对你有帮助。
01-26 1609
雪花算法是twitter1位正数位，即高位为0。41位时间戳5位workerid记录用户维护当前服务器的id号。5位的服务id12位的自增序列对应结构图如下所示：时钟回拨问题：我们都知道雪花算法有41位是时间戳组成，在高并发场景下回拨时间很可能出现相同的时间戳，很可能造成id冲突的场景。无法满足多分片键场景，雪花算法虽能保证id唯一，对于单一条件绰绰有余，一旦遇到多分片键依赖单id的场景就显得力不从心了。举个例子:在商城下单后，我们通过雪花算法生成唯一订单号，根据hash算法。
高效爬虫：一文掌握 FunBoost 的各种使用（万能分布式函数调度框架）
最新发布
数据知道的博客
04-28 727
FunBoost是分布式函数调度框架，支持5种并发模式，20+种消息中间件，30种任务控制功能。用途概念就是常规经典的 生产者 + 消息队列中间件 + 消费者 编程思想。有了这个框架，用户再也无需亲自手写操作进程、线程、协程的并发的代码了。有了这个框架，用户再也无需亲自手写操作redis rabbitmq socket kafka celery nameko了。funboost的功能是全面性重量级，用户能想得到的功能99%全都有;
分布式发号器
09-20
这个是基于Snow flake算法改良的，可以支持分布式和高并发生成订单号。
分布式ID介绍及实现方案总结
欢迎来到空说的博客
03-13 1240
分布式 ID 指的是 分布式系统下的 ID，属于计算机系统中的一个概念。这个一般在分库分表场景，有分布式 ID 的需求，因为需要有一个唯一标识来标记一个订单或者其他类似的数据等。项目上线后，随着使用人数越来越多，整个系统的数据量将越来越大。单机 MySQL 已经没办法支撑了，需要进行分库分表（推荐 Sharding-JDBC）在分库之后，数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。这个时候就需要生成了。：ID 的全局唯一性肯定是首先要满足的！
一口气说出 9种 分布式ID生成方式，面试官有点懵了
weijia521的博客
10-20 426
一口气说出 9种 分布式ID生成方式，面试官有点懵了 码农沉思录7月30日 以下文章来源于程序员内点事，作者程序员内点事 一、为什么要用分布式ID？ 在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？ 1、什么是分布式ID？ 拿MySQL数据库举个栗子： 在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。 但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分...
实战--分布式id发号器
Danny_idea的博客
12-22 993
在经过了众多轮的面试之后，小林终于进入到了一家互联网公司的基础架构组，小林目前在公司有使用到架构组研究到分布式id生成器，前一阵子大概看了下其内部的实现，发现还是存在一些架构设计不合理之处。但是又由于适用于当前的业务场景，所以并没有做过多的优化，这里记录一些相关的技术笔记。 研发背景 在分布式服务中，各种复杂的业务场景需要有一个用于做唯一标识的id，例如订单业务，支付流水，聊天通信等业务场景。尤其是在分库分表场景中，分布式id生成器的使用频率更高。因此分布式id组件的设计应该要能支持以下几个特性： 1.全局
分布式系统之发号器
随意编程者
09-25 938
发号器在分布式系统中是一个非常重要的组件，主要用于生成唯一的标识符，以确保系统中各个服务或节点可以正确地识别和处理请求。
分布式ID解决方案
WGH100817的博客
11-16 140
...
​分布式定时任务框架Quartz
weixin_38328252的博客
12-23 1137
前言 项目中总要写那么几个定时任务来处理一些事情。一些简单的定时任务使用Spring自带的定时任务就能完成。但是如果需要大量的定时任务的话要怎么才能统一管理呢？ 本文介绍Quartz分布式调度框架。 介绍 Quartz介绍 Quartz是OpenSymphony开源组织在Job scheduling领域又一个开源项目，是完全由java开发的一个开源的任务日程管理系统。 目前是 Terracott...
一文看懂分布式存储架构
热门推荐
weixin_70730532的博客
07-29 2万+
目录一、集中存储结构二、分布式存储1 、分布式存储的兴起2 、分布式存储的重要性3 、分布式存储的种类和比较三、分布式理论浅析1 、一致性和可用性2 、数据分布3 、复制4 、分布式协议5、跨机房部署四、分布式文件系统1、 Google 文件系统（ GFS ）2、 Taobao 文件系统（ TFS ）3、 Fackbook Haystack 文件系统4、 CDN 内容分发网络五、分布式键值系统1、 Amazon Dynamo2、 Taobao Tiar3、 ETCD4 、产品选型比较（ Etcd ， Zoo
分布式系统的三个断路器框架的原理和实践
mall4j的博客
04-23 594
分布式系统的三个断路器框架的原理和实践 springboot实战电商项目mall4j （https://gitee.com/gz-yami/mall4j） java开源商城系统 ​ 随着微服务的流行，熔断作为其中一项很重要的技术也广为人知。当微服务的运行质量低于某个临界值时，启动熔断机制，暂停微服务调用一段时间，以保障后端的微服务不会因为持续过负荷而宕机。本文介绍了Hystrix、新一代熔断器Resilience4j以及阿里开源的Sentinel如何使用。如有错误欢迎指出。 1. 为什么需要断路器 ​
基于数据库的分布式发号器-viemall-sequence
04-15
基于数据库的分布式发号器-viemall-sequence基于数据库的分布式发号器-viemall-sequence基于数据库的分布式发号器-viemall-sequence基于数据库的分布式发号器-viemall-sequence基于数据库的分布式发号器-viemall-sequence
分布式ID方案有哪些以及各自的优劣势，我们当如何选择
hl_java的专栏
11-06 7356
分布式ID方案有哪些以及各自的优劣势，我们当如何选择作者介绍 段同海，就职于达达基础架构团队，主要参与达达分布式ID生成系统，日志采集系统等中间件研发工作。背景在分布式系统中，经常需要对大量的数据、消息、http请求等进行唯一标识，例如：在分布式系统之间http请求需要唯一标识，调用链路分析的时候需要使用这个唯一标识。这个时候数据库自增主键已经不能满足需求，需要一个能够生成全局唯一ID的系统
分布式发号器（1）
船长
06-16 373
为什么不用UUID UUID虽然能够保证ID的唯一性，但是，它无法满足业务系统需要的很多其他特性，例如：时间粗略有序性，可反解和可制造型。 另外，UUID产生的时候使用完全的时间数据，性能比较差，并且UUID比较长，占用空间大，间接导致数据库性能下降，更重要的是， UUID并不具有有序性，这导致B+树索引在写的时候会有过多的随机写操作（连续的ID会产生部分顺序写），另外写的时候由于不能 产生...
分布式系统-发号器
厚积薄发
03-16 872
当需要生成新的ID时，先获取当前时间戳，然后判断当前时间戳是否小于上次生成ID时的时间戳。如果小于，则表示发生了时钟回拨，此时需要计算时间戳差值并加上序列号，得到一个新的时间戳，然后将序列号重置为0。如果不小于，则直接将序列号加1，并更新上次生成ID时的时间戳。具体而言，如果在同一毫秒内发生了时钟回拨，则需要将序列号减去回拨的毫秒数，这样才能确保在同一毫秒内生成的ID不重复。其中，时间戳部分占用42位（即时间戳-开始时间戳左移22位），数据中心ID部分占用5位，机器ID部分占用5位，序列号部分占用12位。
微服务分布式事务:全局唯一id发号器
liymaVR的博客
11-25 1261
分布式系统中，产生唯一流水号的服务系统俗称发号器。 有很多发号器开源项目，这里使用 EasyIdGenerator，具体项目信息请访问：https://github.com/lookingatstarts/easyIdGenerator 项目使用非常简单，将项目下载下来稍作配置即可。 下载地址:访问https://github.com/lookingatstarts/easyIdGenerator，下载发号器项目。 解压后放在自己子工程同级下 添加pom依赖 <?xml ver...
【架构】一款永不重复的高性能分布式发号器，实战nginxpdf
m0_64867839的博客
12-12 654
零、基本术语 发号器：用于生成唯一流水号（也即俗称的唯一ID）的服务系统，称之为发号器 一、技术选型 UUID 优点：能够保证唯一性 缺点：（1）完全的时间数据=>性能比较差、比较长、占用空间大、间接导致数据库性能下降;（2）无序=>导致B+树索引在写的时候会有过多的随机写操作，不会产生有顺序的append操作，而是需要进行insert操作，这将读取整个B+树节点到内存并在插入该条记录后会将整个节点写会磁盘=>在记录占用空间比较大的情况下，写的性能会明显下降 数据库 单库时（自增字段）：局
架构设计-分布式ID
sinat_34814635的博客
04-29 2155
比如单机 MySQL 数据库，前期因为业务量不大，只是使用单个数据库存数据，后期发现业务量一下子就增长，单机 MySQL 已经不能满足于现在的数据量，单机 MySQL 已经没办法支撑了，这时候就需要进行分库分表。
web session
03-17
### Web会话管理在Web应用中的重要性 Web会话管理是构建动态交互式Web应用的核心组件之一。它允许服务器跟踪用户的活动状态，从而提供个性化的用户体验[^1]。对于单用户桌面应用程序而言，由于只有一个用户存在，因此连接用户与其会话数据相对简单。然而，在多客户端的Web环境中，服务器如何区分不同用户的会话成为了一个挑战。这一问题通过引入会话ID得以解决[^2]。 #### 会话管理的工作原理 当用户首次访问网站时，服务器创建一个新的会话并将唯一的标识符分配给该用户——即所谓的会话ID。此ID通常存储在一个HTTP Cookie中，并随每次请求发送回服务器，以便识别特定用户的会话数据。如果浏览器禁用了Cookie，则可以采用URL重写或其他机制来传递会话信息。 以下是基于Java Server Pages (JSP) 的典型会话管理方式： ```java // 获取当前HttpSession对象 HttpSession session = request.getSession(); // 设置属性到session中 session.setAttribute("username", "JohnDoe"); // 读取session中的属性 String username = (String) session.getAttribute("username"); ``` 上述代码片段展示了如何利用`request.getSession()`获取现有的或者新建一个HttpSession实例，以及怎样向其中存入和取出键值对形式的数据。 #### 安全考量 尽管会话管理极大地增强了Web应用的功能性，但它也带来了潜在的安全风险。攻击者可能尝试窃取合法用户的会话令牌以冒充他们登录系统。为此，《Best Practices for Creating Secure Web Applications》一文中提到过一些增强安全性措施的重要性[^4]。例如，应该始终启用HTTPS协议加密传输层上的通信；定期更新或销毁不再活跃的会话以防泄露敏感资料等。 另外值得注意的是，在跨多个子域部署的应用场景下实施统一身份验证方案（Single Sign-On, SSO），这不仅简化了用户体验还能提高整体系统的防护水平[^3]。 #### 集群环境下的会话共享 随着分布式计算的发展趋势日益明显，越来越多的企业开始将其服务迁移到集群架构上来提升性能与可靠性。在这种情况下保持各节点间的一致性变得尤为重要。像Shiro这样的框架支持借助Hazelcast之类的第三方库来进行集中式的会话复制操作，即使是在非传统意义上的Web上下文中也能正常运作[^5]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值