消息队列中的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分别消费了一次。

相关推荐
qq_256247056 小时前
从“人工智障”到“神经网络”:一口气看懂 AI 的核心原理
后端
无心水6 小时前
分布式定时任务与SELECT FOR UPDATE:从致命陷阱到优雅解决方案(实战案例+架构演进)
服务器·人工智能·分布式·后端·spring·架构·wpf
用户400188309376 小时前
手搓本地 RAG:我用 Python 和 Spring Boot 给 AI 装上了“实时代码监控”
后端
用户3414081991256 小时前
/dev/binder 详解
后端
Gopher_HBo7 小时前
Go进阶之recover
后端
程序员布吉岛7 小时前
写了 10 年 MyBatis,一直以为“去 XML”=写注解,直到看到了这个项目
后端
却尘7 小时前
一篇小白也能看懂的 Go 字符串拼接 & Builder & cap 全家桶
后端·go
茶杯梦轩7 小时前
从零起步学习Redis || 第七章:Redis持久化方案的实现及底层原理解析(RDB快照与AOF日志)
redis·后端
QZQ541887 小时前
重构即时IM项目13:优化消息通路(下)
后端
柠檬味拥抱7 小时前
揭秘Cookie操纵:深入解析模拟登录与维持会话技巧
后端