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

相关推荐
uzong1 天前
9 种 RAG 架构,每位 AI 开发者必学:完整实战指南
后端
小江的记录本1 天前
【Kafka核心】架构模型:Producer、Broker、Consumer、Consumer Group、Topic、Partition、Replica
java·数据库·分布式·后端·搜索引擎·架构·kafka
止语Lab1 天前
从手动到框架:Go DI 演进的三个拐点
开发语言·后端·golang
Daybreak1 天前
Elasticsearch 里的索引和 Mapping,到底是什么关系?
后端
Lee川1 天前
Prisma 实战指南:像搭积木一样设计古诗词数据库
前端·数据库·后端
李小狼lee1 天前
深入浅出sse协议,用代码自己实现
后端
SamDeepThinking1 天前
并发量就算只有2,该上锁还得上呀
java·后端·架构
永远不会的CC1 天前
浙江华昱欣实习(4月23日~ 4月19日)
后端·学习