分布式唯一ID生成（二）: leaf

文章目录

  • 本系列
  • 前言
  • 号段模式
    • 双buffer优化
    • biz优化
    • 动态step
    • 源码走读
  • 雪花算法
    • 怎么设置workerId
    • 解决时钟回拨
    • 源码走读
  • 总结

本系列

  • 漫谈分布式唯一ID
  • 分布式唯一ID生成（二）：leaf（本文）
  • 分布式唯一ID生成（三）：uid-generator
  • 分布式唯一ID生成（四）：tinyid

前言

本文将介绍leaf号段模式和雪花算法模式的设计原理，并走读源码

源码地址：https://github.com/Meituan-Dianping/Leaf

leaf提供了 leaf server，业务只管调leaf server的接口获取ID，leaf serve内部根据号段或雪花算法生成ID，而不是业务服务自己去请求数据库生成id，或自己根据雪花算法生成id

在这里插入图片描述


号段模式

在使用db自增主键的基础上，从每次获取ID都要读写一次db，改成一次获取一批ID

各个业务的记录通过 biz_tag 区分，每个业务的ID上次分配到哪了，在一张表中用一条记录表示

表结构如下：

CREATE TABLE `leaf_alloc` (`biz_tag` varchar(128)  NOT NULL DEFAULT '', -- your biz unique name`max_id` bigint(20) NOT NULL DEFAULT '1',`step` int(11) NOT NULL,`description` varchar(256)  DEFAULT NULL,`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;

重要字段为：

  • biz_tag：标识业务
  • max_id：目前分配到的最大值-1，也是 下一个号段的起始值
  • step：每次分配号段的长度

如果step=1000，当这1000个ID消耗完后才会读写一次DB，对DB的压力降为原来的 1/1000

当缓存中没有ID时，需要从db获取号段，在事务中执行如下2条sql：

UPDATE leaf_alloc SET max_id = max_id + step WHERE biz_tag = #{tag}

SELECT biz_tag, max_id, step FROM leaf_alloc WHERE biz_tag = #{tag}

然后加载到本地

N个server执行上述操作，对外提供http接口用于生成id，整体架构如下图所示：

在这里插入图片描述

优点：

  • Leaf服务可以很方便的线性扩展，例如按照biz_tag分库分表
  • ID是趋势递增的64位数字，满足上述数据库存储的类型要求
  • 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内仍能正常对外提供服务
  • 易接入：可自定义初始max_id的值，方便业务从原有的ID方式上迁移过来

缺点：

  • 业务上不够安全：ID近似于严格递增，会泄露发号数量的信息

  • TP999显著比其他TP值大：当号段使用完之后还是会hang在更新数据库的I/O上

    • 以step=1000为例，99.9%的请求分配ID都非常快，0.1%的请求会比较慢（读写一次db平均5ms），如果恰好遇到db抖动，耗时能到几秒

  • 单点问题：DB如果宕机会造成整个系统不可用

  • 网络IO开销大：client每获取一个id，都要对leaf server发起一次http调用


双buffer优化

针对TP999大的问题，Leaf号段模式做了一些优化：在内存中维护两个号段，在当前号段消费到一定百分比时，就 异步去db加载下一个号段 到内存中
这样当前号段用完后，就能马上切换到下一个号段

在这里插入图片描述

biz优化

对于每个请求，都需要校验参数中的biz是否合法。如果每次都去db查下biz在leaf_alloc表是否存在，性能开销大且没必要

leaf在实例启动时，将全量biz都查出来放到本地缓存中，之后每隔60s都会刷新一次，这样校验biz是否合法都用本地map判断，性能极高

缺点是最多延迟1分钟才新增的biz才生效

也就牺牲一点一致性换取超高的性能


动态step

如果每次获取号段的长度step是固定的，但流量不是固定的，如果流量增加 10 倍，每个号段很快就被用完了，仍然有可能导致数据库压力较大

同时也降低了可用性，例如本来能在DB不可用的情况下维持10分钟正常工作，那么如果流量增加10倍就只能维持1分钟正常工作了

因此leaf中每次从db加载号段时，加载多少ID并不是固定的

  • 如果qps高，就可以一次多加载点，减少调db的次数
  • 如果qps低，可以一次少加载点。否则在缓存中的号段迟迟消耗不完的情况下，会导致更新DB的新号段与前一次下发的号段ID跨度过大

leaf的策略为每次更新buffer时动态维护step，当需要从db加载号段时，计算距离上次从db加载过去了多久：

  • 小于15mins：获取的号段长度翻倍
  • 15～30mins：获取的号段长度和上次一样
  • 大于30mins：获取的号段长度减半

源码走读

初始化：

public boolean init() {// 将所有biz加载到内存updateCacheFromDb();initOK = true;// 后台每1s刷新一次内存中的bizupdateCacheFromDbAtEveryMinute();return initOK;
}

获取ID流程如下：

public Result get(final String key) {if (!initOK) {return new Result(EXCEPTION_ID_IDCACHE_INIT_FALSE, Status.EXCEPTION);}// 校验biz是否合法if (cache.containsKey(key)) {SegmentBuffer buffer = cache.get(key);if (!buffer.isInitOk()) {synchronized (buffer) {if (!buffer.isInitOk()) {try {// 号段未初始化，从db加载号段updateSegmentFromDb(key, buffer.getCurrent());buffer.setInitOk(true);} catch (Exception e) {}}}}// 从号段获取IDreturn getIdFromSegmentBuffer(cache.get(key));}return new Result(EXCEPTION_ID_KEY_NOT_EXISTS, Status.EXCEPTION);
}

getIdFromSegmentBuffer方法：

public Result getIdFromSegmentBuffer(final SegmentBuffer buffer) {while (true) {buffer.rLock().lock();try {final Segment segment = buffer.getCurrent();// 如果当前号段已经用了10%，异步去加载下一个号段if (!buffer.isNextReady() && (segment.getIdle() < 0.9 * segment.getStep()) && buffer.getThreadRunning().compareAndSet(false, true)) {service.execute(new Runnable() {@Overridepublic void run() {// 加载下一个号段});}// 当前号段还没用完，从当前号段获取long value = segment.getValue().getAndIncrement();if (value < segment.getMax()) {return new Result(value, Status.SUCCESS);}} finally {buffer.rLock().unlock();}// 到这说明当前号段用完了waitAndSleep(buffer);buffer.wLock().lock();try {// 再次检查当前号段，因为可能别的线程加载了final Segment segment = buffer.getCurrent();long value = segment.getValue().getAndIncrement();if (value < segment.getMax()) {return new Result(value, Status.SUCCESS);}// 切换到下一个号段，重新执行while循环获取if (buffer.isNextReady()) {buffer.switchPos();buffer.setNextReady(false);} else {// 两个号段都不可用，报错return new Result(EXCEPTION_ID_TWO_SEGMENTS_ARE_NULL, Status.EXCEPTION);}} finally {buffer.wLock().unlock();}}}

最后看下怎么从db加载号段： 
public void updateSegmentFromDb(String key, Segment segment) {SegmentBuffer buffer = segment.getBuffer();LeafAlloc leafAlloc;// ...// 动态调整下一次的steplong duration = System.currentTimeMillis() - buffer.getUpdateTimestamp();int nextStep = buffer.getStep();if (duration < SEGMENT_DURATION) {if (nextStep * 2 > MAX_STEP) {} else {nextStep = nextStep * 2;}} else if (duration < SEGMENT_DURATION * 2) {} else {nextStep = nextStep / 2 >= buffer.getMinStep() ? nextStep / 2 : nextStep;}LeafAlloc temp = new LeafAlloc();temp.setKey(key);temp.setStep(nextStep);// 从db获取下一个号段leafAlloc = dao.updateMaxIdByCustomStepAndGetLeafAlloc(temp);buffer.setUpdateTimestamp(System.currentTimeMillis());buffer.setStep(nextStep);buffer.setMinStep(leafAlloc.getStep());// 加载到内存中long value = leafAlloc.getMaxId() - buffer.getStep();segment.getValue().set(value);segment.setMax(leafAlloc.getMaxId());segment.setStep(buffer.getStep());
}

内存中Segment结构主要有以下字段：
  • value：下一个要分配的ID
  • max：当前号段的最大边界

每次从Segment中分配ID时，返回value的值即可，并把value++


雪花算法

号段模式的ID很接近严格递增，如果在订单场景，可以根据ID猜到一天的订单量。此时就可以用雪花算法模式

leaf在每一位的分配和标准snowflake一致：
在这里插入图片描述

  • 最高位符号位为0

  • 接下来41位：毫秒级时间戳

    • 存储当前时间距离2010年某一天的差值

  • 接下来10位：workerId

  • 最后12位：每一毫秒内的序列号

每到新的毫秒时，每一毫秒内的序列号不是从0开始，而是从100以内的一个随机数开始

为啥这么设计？试想如果每一秒都从0开始，在qps低的情况下，每一毫秒只产生1个id，那么最末尾永远是0。如果对ID取模分表，就会永远在第0号表，造成数据分布不均


怎么设置workerId

对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。如果服务规模较大，动手配置成本太高。于是leaf用zookeeper 自动获取workerId，流程如下：

  1. 以自己的 ip:port为key，去zk建立持久顺序节点，以zk生成的 自增序号为workerId

    1. 创建的节点最后两级路径为：/forever/ip:port-序列号

  2. 如果zk中已经有自己ip:port的节点，就 复用 其workerId

    1. 怎么判断？拉取/forever下所有节点，每个节点的格式为ipport-序列号，判断每个节点中-前面的ipport是不是等于自己，如果等于取-后面的序列号作为workerId
    2. 只有leaf server会创建zk节点，因此节点数量可控
    3. 为啥可以复用？不会在同一时刻，有相同ip:port的两个实例，因此复用一定不会发生冲突

这种workerId分配策略能保证唯一性吗？能

  • 如果 ip:port 不同，在zk中一定是两个不同的序列号，因此不会冲突
  • 一个集群中不可能同时存在ip:port相同的两个机器

每个leaf server的ip:port最好手动指定，或者部署在ip不会变化的环境中

高可用：workerId会存到本地文件，这样遇到极端情况：leaf server服务重启，且zk也宕机时，也不影响使用
在这里插入图片描述


解决时钟回拨

雪花算法严格依赖时间，如果发生了时钟回拨，就可能导致ID重复，因此需要监测是否发生了时钟回拨并处理，在服务启动和运行时都会检测

在服务启动时检测时间是否回退：

  • leaf server运行时，每隔3s会上自己的当前时间到zk节点中
  • 启动时，校验当前时间不能小于 zk中最近一次上报的时间

官方文档还提到如果是第一次启动，还会和其他leaf server校准时间。但源码中没找到这部分，应该是不需要做这个校准，已删除

在运行时检测时间是否回退：

  • 全局维护了上次获取ID时的时间戳：lastTimestamp

  • 如果当前时间 now < lastTimestamp，说明发生了时钟回拨

    • 回拨了超过5ms，返回报错
    • 回拨了5ms内，sleep一会，直到赶上上次时间

如果zk宕机导致定时上报没有成功，同时又发生了时钟回拨，且leaf server宕机。此时leaf server启动时可能产生和之前重复的ID。因此需要做好监控告警，zk的高可用

如果3s内没上报，leaf server宕机了，然后时钟回退了2s，此时根据zk的时间检测不出来发生了时钟回退，也会造成ID重复。解决方法就是等一段时间才重启机器，保证等待的时间比回拨的时间长就行


源码走读

初始化：

public boolean init() {try {CuratorFramework curator = createWithOptions(connectionString, new RetryUntilElapsed(1000, 4), 10000, 6000);curator.start();Stat stat = curator.checkExists().forPath(PATH_FOREVER);if (stat == null) {//不存在根节点,机器第一次启动,创建/snowflake/ip:port-000000000,并上传数据zk_AddressNode = createNode(curator);//worker id 默认是0，存到本地文件updateLocalWorkerID(workerID);//每3s上报本机时间给forever节点ScheduledUploadData(curator, zk_AddressNode);return true;} else {Map<String, Integer> nodeMap = Maps.newHashMap();//ip:port->00001Map<String, String> realNode = Maps.newHashMap();//ip:port->(ipport-000001)//存在根节点,先检查是否有属于自己的节点List<String> keys = curator.getChildren().forPath(PATH_FOREVER);for (String key : keys) {String[] nodeKey = key.split("-");realNode.put(nodeKey[0], key);nodeMap.put(nodeKey[0], Integer.parseInt(nodeKey[1]));}Integer workerid = nodeMap.get(listenAddress);if (workerid != null) {//有自己的节点,zk_AddressNode=ip:portzk_AddressNode = PATH_FOREVER + "/" + realNode.get(listenAddress);workerID = workerid;//启动worder时使用会使用// 当前时间不能小于 zk中最近一次上报的时间if (!checkInitTimeStamp(curator, zk_AddressNode)) {throw new CheckLastTimeException("init timestamp check error,forever node timestamp gt this node time");}// 每3s上报时间doService(curator);// 将workerId写到本地updateLocalWorkerID(workerID);} else {//新启动的节点,创建持久节点 ,不用check时间String newNode = createNode(curator);zk_AddressNode = newNode;String[] nodeKey = newNode.split("-");workerID = Integer.parseInt(nodeKey[1]);doService(curator);updateLocalWorkerID(workerID);}}} catch (Exception e) {// zk不可用，从本地文件加载workerIdtry {Properties properties = new Properties();properties.load(new FileInputStream(new File(PROP_PATH.replace("{port}", port + ""))));workerID = Integer.valueOf(properties.getProperty("workerID"));} catch (Exception e1) {return false;}}return true;}

获取ID：

public synchronized Result get(String key) {long timestamp = timeGen();// 发生了时钟回拨if (timestamp < lastTimestamp) {long offset = lastTimestamp - timestamp;// 回拨了5ms内，sleep一会if (offset <= 5) {try {wait(offset << 1);timestamp = timeGen();if (timestamp < lastTimestamp) {return new Result(-1, Status.EXCEPTION);}} catch (InterruptedException e) {return new Result(-2, Status.EXCEPTION);}// 回拨了超过5ms，返回报错} else {return new Result(-3, Status.EXCEPTION);}}// 和上次在同一毫秒if (lastTimestamp == timestamp) {sequence = (sequence + 1) & sequenceMask;if (sequence == 0) {//seq 为0表示是当前ms已经超过4096个ID了// 需要sleep一会，下一毫秒时间开始对seq做随机sequence = RANDOM.nextInt(100);timestamp = tilNextMillis(lastTimestamp);}} else {//如果是新的ms, 对seq做随机sequence = RANDOM.nextInt(100);}lastTimestamp = timestamp;long id = ((timestamp - twepoch) << timestampLeftShift) | (workerId << workerIdShift) | sequence;return new Result(id, Status.SUCCESS);}

总结

leaf提供两种分布式ID生成策略：

  • 号段模式：

    • 每次从db获取一批ID，而不是一个ID，减少调DB的频率
    • 用双buffer解决TP999耗时高的问题
    • 在内存判断参数biz是否合法，提高校验性能
    • 使用动态step，解决突发流量造成对db压力仍然大的问题

  • 雪花算法模式：

    • 配合ZK做到动态获取workerId，解决海量机器的 workId 维护问题，也能保证正确性：同时不会有两个leaf server拥有相同的workerId
    • 在服务启动时和运行时都校验是否发生了时钟回拨。不过服务启动时的校验有时会失效，最好sleep一段时间再重启，这段时间要大于时钟回拨的时间

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/pingmian/59930.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

MVDR：最小方差无失真响应技术解析

MVDR：最小方差无失真响应技术解析

目录 什么是MVDR&#xff1f;MVDR的工作原理主要步骤MVDR的应用场景MVDR的优势与挑战结论 什么是MVDR&#xff1f; MVDR&#xff08;Minimum Variance Distortionless Response&#xff0c;最小方差无失真响应&#xff09;是一种用于信号处理中的自适应滤波技术&#xff0c;广…
阅读更多...
Flink安装和Flink CDC实现数据同步

Flink安装和Flink CDC实现数据同步

一&#xff0c;Flink 和Flink CDC 1&#xff0c; Flink Apache Flink是一个框架和分布式处理引擎&#xff0c;用于对无界和有界数据流进行有状态计算。 中文文档 Apache Flink Documentation | Apache Flink 官方文档 &#xff1a;https://flink.apache.org Flink 中文社区…
阅读更多...
【React.js】AntDesignPro左侧菜单栏栏目名称不显示的解决方案

【React.js】AntDesignPro左侧菜单栏栏目名称不显示的解决方案

作者&#xff1a;CSDN-PleaSure乐事 欢迎大家阅读我的博客 希望大家喜欢 使用环境&#xff1a;WebStorm 目录 问题概述 原因 解决方案 解决方法 潜在问题修改 最终效果呈现 额外内容 管理员界面路由配置 WebStorm背景更换 法一&#xff1a; 法二&#xff1a; 问题概…
阅读更多...
MCU面试题

MCU面试题

面试题 1、Crotex-M 处理器才用的架构是"v7" Cortex-M3处理器是基于ARMv7-M架构的处理器&#xff0c;支持更丰富的指令集&#xff0c;包括许多32位指令&#xff0c;这些指令可以高效的使用高位寄存器。另外&#xff0c;M3还支持&#xff1a; 查表跳转指令和条件执行&…
阅读更多...
Mysql COUNT() 函数详解

Mysql COUNT() 函数详解

在使用Mysql的时候&#xff0c;作为开发者&#xff0c;聚合函数是肯定会用到的&#xff0c;下面就来说说我们常用到的统计行数的聚合函数 COUNT()。 COUNT() 的几种用法 说到COUNT() 函数&#xff0c;最常用的几种方法就是 COUNT(*) 、COUNT(1)、 COUNT(column)&#xff0c;那…
阅读更多...
基于SSM的图书馆座位预约系统+lw示例参考

基于SSM的图书馆座位预约系统+lw示例参考

#1.项目介绍 系统角色&#xff1a;管理员、普通用户功能模块&#xff1a;管理员&#xff08;用户管理、座位管理、座位分类管理、图书馆管理、预约信息管理、退座管理、系统管理等&#xff09;、普通用户&#xff08;信息查看、图书馆管理、个人中心、座位预约等&#xff09;技…
阅读更多...
【数字图像处理+MATLAB】计算并显示灰度图像的直方图（Histogram）：使用 imhist 函数

【数字图像处理+MATLAB】计算并显示灰度图像的直方图（Histogram）：使用 imhist 函数

引言 imhist 是 MATLAB 中的一个函数&#xff0c;用于计算并显示图像的直方图。 直方图是一种统计工具&#xff0c;用于显示图像中各个亮度级别的像素数量。直方图的垂直轴表示像素数量&#xff0c;水平轴表示亮度级别。 函数详解 基本语法&#xff1a; imhist(I) imhist(I…
阅读更多...
了解云计算工作负载保护的重要性及必要性

了解云计算工作负载保护的重要性及必要性

云计算de小白 云计算技术的快速发展使数据和应用程序安全成为一种关键需求&#xff0c;而不仅仅是一种偏好。随着越来越多的客户公司将业务迁移到云端&#xff0c;保护他们的云工作负载&#xff08;指所有部署的应用程序和服务&#xff09;变得越来越重要。云工作负载保护&…
阅读更多...
windows server2019下载docker拉取redis等镜像并运行项目

windows server2019下载docker拉取redis等镜像并运行项目

一、基本概念 1、windows server 指由微软公司开发的“Windows”系列中的“服务器”版本。这意味着它是基于Windows操作系统的&#xff0c;但专门设计用于服务器环境&#xff0c;而不是普通的桌面或个人用户使用。主要用途包括服务器功能、用户和资源管理、虚拟化等 2、dock…
阅读更多...
UE5.4 PCG 使用Union和Difference给菜地开路

UE5.4 PCG 使用Union和Difference给菜地开路

效果&#xff1a;
阅读更多...
0. 渲染游戏画面

0. 渲染游戏画面

1 用到的函数 # initialize env env gym.make() frame env.render() frame np.transpose(frame, (1, 0, 2)) # 调整图像方向 frame pygame.surfarray.make_surface(frame) screen.blit(frame, (0, 0)) pygame.display.flip()1.1 检查图像的形状 首先&#xff0c;我们…
阅读更多...
【西藏】《西藏自治区本级政务信息化项目建设和运维费用预算支出标准》（藏财建〔2024〕68号）－省市费用标准解读系列08

【西藏】《西藏自治区本级政务信息化项目建设和运维费用预算支出标准》（藏财建〔2024〕68号）－省市费用标准解读系列08

2024年9月1日&#xff0c;西藏自治区财政厅和经济和信息化厅正式施行最新信息化建设和运维项目预算支出标准《西藏自治区本级政务信息化项目建设和运维费用预算支出标准》&#xff08;藏财建〔2024〕68号&#xff09;&#xff08;以下简称“68号文”&#xff09;。同时&#xf…
阅读更多...
Autosar CP Transformer规范工作原理和应用场景导读

Autosar CP Transformer规范工作原理和应用场景导读

一、AUTOSAR规范中Transformer的主要功能和分类 &#xff08;一&#xff09;主要功能 数据转换与处理 从运行时环境&#xff08;RTE&#xff09;获取数据&#xff0c;进行序列化&#xff08;将复杂数据结构转换为线性字节数组&#xff09;或其他转换操作&#xff08;如添加校…
阅读更多...
【网络安全 | 并发问题】Nginx重试机制与幂等性问题分析

【网络安全 | 并发问题】Nginx重试机制与幂等性问题分析

未经许可，不得转载。 文章目录 业务背景Nginx的错误重试机制proxy_next_upstream指令配置重试500状态码非幂等请求的重试问题幂等性和非幂等性请求non_idempotent选项的使用解决方案业务背景 在现代互联网应用中，高可用性（HA）是确保系统稳定性的关键要求之一。为了应对服务…
阅读更多...
天津营业执照注销流程

天津营业执照注销流程

营业执照不注销会有什么影响&#xff1f;1、公司不经营&#xff0c;放几年自动注销&#xff1f;真相&#xff1a;不管放多长时间&#xff0c;公司是不会自动注销的。相反&#xff0c;放任长久不维护&#xff0c;公司会出现异常&#xff0c;营业执照被吊销&#xff0c;公司股东、…
阅读更多...
MySQL数据库专栏（五）连接MySQL数据库C API篇

MySQL数据库专栏（五）连接MySQL数据库C API篇

摘要 本篇文章主要介绍通过C语言API接口链接MySQL数据库&#xff0c;各接口功能及使用方式&#xff0c;辅助类的封装及调用实例&#xff0c;可以直接移植到项目里面使用。 目录 1、环境配置 1.1、添加头文件 1.2、添加库目录 2、接口介绍 2.1、MySql初始化及数据清理 2.1.…
阅读更多...
计算机课程管理：Spring Boot实现的工程认证路径

计算机课程管理：Spring Boot实现的工程认证路径

摘要 随着信息技术在管理上越来越深入而广泛的应用&#xff0c;管理信息系统的实施在技术上已逐步成熟。本文介绍了基于工程教育认证的计算机课程管理平台的开发全过程。通过分析基于工程教育认证的计算机课程管理平台管理的不足&#xff0c;创建了一个计算机管理基于工程教育认…
阅读更多...
【无人机设计与控制】无人机集群路径规划：5种最新优化算法（ECO、AOA、SFOA、MGO、PLO）求解无人机集群路径规划

【无人机设计与控制】无人机集群路径规划：5种最新优化算法（ECO、AOA、SFOA、MGO、PLO）求解无人机集群路径规划

摘要 本文提出了基于无人机集群路径规划的研究&#xff0c;通过使用五种最新优化算法&#xff08;ECO、AOA、SFOA、MGO、PLO&#xff09;进行求解。这些算法主要优化无人机在复杂环境中的路径&#xff0c;以实现多目标规划问题的高效解。实验结果表明&#xff0c;不同算法在收…
阅读更多...
从0开始搭建一个生产级SpringBoot2.0.X项目（十）SpringBoot 集成RabbitMQ

从0开始搭建一个生产级SpringBoot2.0.X项目（十）SpringBoot 集成RabbitMQ

前言 最近有个想法想整理一个内容比较完整springboot项目初始化Demo。 SpringBoot集成RabbitMQ RabbitMQ中的一些角色&#xff1a; publisher&#xff1a;生产者 consumer&#xff1a;消费者 exchange个&#xff1a;交换机&#xff0c;负责消息路由 queue&#xff1a;队列…
阅读更多...
牧神记开分9.7，2024新国漫巅峰出现了

牧神记开分9.7，2024新国漫巅峰出现了

现在国漫越来越卷了&#xff0c;卷播放量也卷评分。最近&#xff0c;b站上线不久的国漫《牧神记》开分9.7&#xff0c;口碑还是相当不错的&#xff0c;已经和《凡人修仙传》评分齐平。这部国漫仅仅播出4集&#xff0c;为什么就能获得这么高的评分呢&#xff1f;下面就一起来看看…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023