RocketMQ(一) 核心概念
------------恢复内容开始------------
NameServer :生产者和消费者能通过NameServer查找各主题(Topic)对应的Broker IP列表。多个NameServer组成集群,但是其中节点不通信
Topic :主题,代表一类消息的集合。每个消息只包含一个主题,一个主题可以有多个消息。主题是RocketMQ消息订阅的基本类型
message :消息,是传输信息的物理载体,生产和消费数据产生的最小单位,每条消息必须有一个主题。在RocketMQ中每个消息都有一个唯一的MessageID,还有业务标识的Key。系统提供了通过ID和Key查询消息的功能
Broker :消息存储服务器。有两个角色,Master和Slave。在RocketMQ中主服务器承担写操作,从服务器作为一个备份。当主服务器存在压力时,从服务器可以进行消息消费。所有 Broker,包含 Slave 服务器每隔 30s 会向 NameServer 发送心跳包,心跳包中会包含存在在 Broker 上所有的 Topic 的路由信息。
Client :消息客户端,包括 Producer(消息发送者)和 Consumer(消费消费者)。客户端在同一时间只会连接一台 NameServer,只有在连接出现异常时才会向尝试连接另外一台。客户端每隔 30s 向 NameServer 发起 Topic 的路由信息查询。NameServer 是在内存中存储 Topic 的路由信息,持久化 Topic 路由信息的地方是在 Broker 中
CustomerGroup :消息消费组,一个消息消费组在启动时需要订阅需要消费的Topic,一个消息消费组可以订阅多个Topic,一个Topic可以被多个消息消费组订阅。
消费模式:
-
广播模式 :消费组内每一个消费者都会消费Topic里面的message,通常用于刷新缓存。
-
集群模式 :一个消费组内所有的消费者都会共同处理一个Topic里面的message,一个消费者消费一部分消息,启动负载均衡
集群模式是非常普遍的模式,符合分布式架构的基本理念,即横向扩容,当前消费者如果无法快速及时处理消息时,可以通过增加消费者的个数横向扩容,快速提高消费能力,及时处理挤压的消息。
消费进度:消费者消费一条消息后需要记录消息消费的进度,这样在消费端重启的时候,继续从上一次消费结束的位置继续消费。在RocketMQ中,消息消费位点的存储是以消费组为单位的
消费模型:
-
并发消费:对于一个队列的消息,消费者都会创建一个线程池来进行消费(对队列的内容进行多线程处理)。偏移量大比偏移量小的更容易(有可能)消费。
-
顺序消费:对于某些特定的场景,如MySQL的binlog场景,需要根据顺序来进行消费。消费者也会创建一个线程池,但是同一个针对队列会加锁
并发消费失败后最多重试16次,每一次的间隔时间不一样。而顺序消费会一直持续到消费成功为止,容易造成消费积压
------------恢复内容结束------------
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性