消息队列中的topic,partition,offset,broker,消费者组

1个topic的消息会分布到多个partition分区中,每个partition中的每条消息都有一个唯一编号 offset(消费者可以通过记录这个offset来知道自己读到了哪个位置,下次接着从这往下读)

一个broker中存着来自不同topic的partition,比如topicA的partition1,topicB的partition2,topicC的partition3......,所以从物理存储来看:topic其实只是一个概念,并不是真实存在的

同一个消费组内的不同消费者是"同事"关系。它们共同分担一个 Topic 的所有 Partitions,目的是为了"更快地"处理完所有消息。一个消息只会被组内的一个"同事"处理。

不同的消费组各自独立地消费**同一个 Topic(前提是这些消费者组都订阅了这个topic)**的完整数据,互不干扰。一个消息会被每一个"订阅者"(消费组)都处理一次。

复制代码

在 Group-A 内部: 组内的某一台机器(比如 Consumer-A1)会获取并处理消息 M。组内的其他机器(Consumer-A2, Consumer-A3)不会再处理这条消息。 在 Group-B 内部: 组内的某一台机器(比如 Consumer-B1)会获取并处理同一条消息 M。 在 Group-C 内部: 组内的某一台机器(比如 Consumer-C1)也会获取并处理同一条消息 M 最终结果是:消息M被 Consumer-A1、 Consumer-B1 和Consumer-C1分别消费了一次。

相关推荐
子兮曰3 天前
jev-ultrafast 深度解析:7 秒订机票的浏览器 Agent 是如何炼成的
前端·后端·agent
子兮曰3 天前
Jev 爆发一周:7 秒 Agent 背后的 System One 生态与三场争议
前端·后端·ai编程
爱勇宝3 天前
ZCode 开源 24 小时:一份没有历史的账本,回答不了"有没有偷代码"
前端·后端·chatglm (智谱)
胡写代码3 天前
别再前后端各写一套表单校验了
java·后端
大勇前进3 天前
原生 PHP 还是 Laravel?小项目到底要不要上框架
后端
yuzhi_liu3 天前
我用 LangGraph4j 实现 Multi-Agent Supervisor
后端
alsmile3 天前
Node-RED 之外,国产规则引擎的新方案:基于标准语法,Go 先行实现
后端·开源·go
大白803 天前
PHP 内存溢出排查思路:看懂报错日志,精准定位问题
后端
二月龙3 天前
PHP 接口返回统一响应封装,让前后端对接更省心
后端
盖伦发发3 天前
软件工程SOLID 五大设计原则
后端·软件工程