惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
宝玉的分享
宝玉的分享
The Cloudflare Blog
Apple Machine Learning Research
Apple Machine Learning Research
V
Visual Studio Blog
Last Week in AI
Last Week in AI
Hugging Face - Blog
Hugging Face - Blog
博客园 - 司徒正美
博客园 - 三生石上(FineUI控件)
A
About on SuperTechFans
MyScale Blog
MyScale Blog
aimingoo的专栏
aimingoo的专栏
Microsoft Security Blog
Microsoft Security Blog
D
Docker
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recent Announcements
Recent Announcements
大猫的无限游戏
大猫的无限游戏
IT之家
IT之家
P
Proofpoint News Feed
L
LangChain Blog
Blog — PlanetScale
Blog — PlanetScale
The GitHub Blog
The GitHub Blog
博客园 - 【当耐特】
Martin Fowler
Martin Fowler

Mobility

从薅 token 到管 skill:我的 pks 工具落地实践 把笔记、微信读书、知乎装进 Obsidian:我基于llm-wiki知识中枢搭建实录 免费AI视频生成器:我如何用零成本做出带旁白字幕的多场景AI视频 Agnes免费模型真能白嫖视频?我改造了ViMax来试试 教你薅token(二):构建agent无关的skills管理工作流 教你薅token:构建agent无关的AI工作流 用 AI Agent 完成 Hexo 主题迁移:从 Next 到 Butterfly 的全自动化实践 Vercel封禁163邮箱后,我是怎么恢复博客的 用LLM管理安全开发规范:一次llm-wiki实践 Vaadin框架教程:Java工程师的前端开发秘籍 hexo多语言方案总结及最佳实践 知乎增强工具-评论时间精确到秒 怎么理解数据库的四个隔离级别 kubernetes是什么-实用向教程 怎么更科学的用知乎摸鱼 读书笔记《系统之美》,如何面对现实中的复杂问题 分布式系统设计中的通用方法 高并发解决方案很难吗?轻松聊清楚高并发设计 SSP,DSP,RTB,ADX都是什么? 讲讲互联网广告的概念与发展 从redolog,undolog到隔离级别,刨根问底,讲清楚事务和ACID java项目低学习成本使用kubernetes的实践经验 剧变中的2021-一个中年工程师的年终总结 kubernetes环境下做金丝雀发布的一种思路 prometheus教程: 一篇文章讲懂prometheus 实现一个简单的java版本高性能获取ip地址所属国家工具 iterm2配置ssh书签, 实现记住密码和自动登录 怎样做一个好的技术分享 云原生究竟是什么 读书笔记 稻盛和夫《干法》-思考应该怎样去工作 review的个人价值
关于rocketmq的readQueue和writeQueue
流沙 · 2019-05-18 · via Mobility

解释一下rocketMq里的messageQueue为什么要拆分成writeQueue和readQueue.

首先,简单介绍一下rocketmq的queue是什么,从网上找了一个rocketMq的架构图。
rocketMq架构
我们知道,使用rocketMq时,我们都是针对一个topic区进行生产或者消费。而messageQueue就是topic的一部分,类似于kafka中分区的概念。queue是consumer消费时的最小单元,也就是说,consumer的数量无法高于queue的数量。

rocketMq中有很特殊的一点是分了writeQueue和readQueue。其实,在绝大对数情况下,这两件事是无法分开的,如果readQueue和writeQueue的数量不一致,会产生非常严重的问题。例如,writeQueue的数量高于readQueue, 就说明有些queue只有写没有读,也就是说会有一部分消息永远都不会消费掉。readQueue多于writeQueue的话,就说明有一部分consumer处在空跑的状态,不可能接收到消息。

那么,rocketMq这么设计的意义在哪里呢。其实,拆分readQueue和writeQueue, 目的就是能让扩容或缩容的过程更加平滑。以扩容为例,可以先增加readQueue的数量,这时候consumer已经能关联到queue上,然后再去修改writeQueue,因为consumer已经扩容完成了,进入新的queue的消息马上就可以被消费掉。这样整个过程就非常平滑且健壮,所有消息都可以及时交给consumer.

大家可以考虑一下如果没有这样的机制应该如何去设计扩容或者缩容的流程,其实,无论如何都会造成一些消息无法被及时处理。说明这种设计是非常巧妙的。

原文地址: https://lichuanyang.top/posts/32580/