rocketMq原理_客户端与namesrv及broker的交互

对于rocketMq客户端来说,无非就两个任务,消息生产与消息消费

对于生产者来说,需要知道消息可以往哪里发送

对于消费者来说,需要知道可以从哪里拉取消息

本文会从客户端与namesrv、broker的交互的角度讲述消息生产与消息消费大致原理,当然,重点还是围绕上文中提出的queue进行讲述

客户端包括生产者与消费者,它们有共同的交互逻辑,也有不一样的交互逻辑:

  • 无论是生产者还是消费者,在启动时都需要指定一个或多个namesrv地址
  • 客户端启动后,会以30秒一次的频率执行心跳注册以及路由更新动作

心跳注册:向所有master broker发送心跳信息(broker的信息来源在下面的路由更新中会介绍),包括消费订阅信息、生产者信息,broker在收到心跳信息后,会将信息提取并保存到内存中

路由更新:

  • 从namesrv列表中随机选取一个,与之建立连接(并将连接保持,后续以此连接为准,直到连接不可用,才会换成另一个namesrv进行连接)
  • 从建立连接的namesrv上拉取所有topic的路由信息,主要包括broker的addr,topic对应的queue信息(也就是在前面一篇"nameserver与broker的交互"中提到的路由信息),会根据返回的queueData中的写队列数(writeNums)创建对应数量的queue,每个queue对应一个queueId,与broker端的queue对应
  • 如此,在客户端的内存中,就可以查到所有broker的连接地址,并且可以根据topic查询到其对应的所有queue{brokerName,queueId}信息了,生产者会以此为根据进行消息的发送,消费者以此为根据进行消息消费

注意,由于路由更新动作定时执行,所以一旦有broker数量变动(新增机器,上线下线),在下一次执行该动作时,内存中的queue列表就会对应更新,那queue列表到底是什么用意?

为什么说queue是消息生产时broker权重分配消息消费能力横向扩展以及broker横向扩容的关键呢?

假设,当前broker集群中有两台master broker,broker1和broker2,其中broker1的可写队列数为2,broker2的可写队列数为3,在控制台创建了一个topicA,现在在客户端第一次拉取路由信息后,客户端的内存中对于topicA,会有5个queue,分别是{broker1,queueId0},{broker1,queueId1},{broker2,queueId0},{broker2,queueId1},{broker2,queueId2},基于这5个queue,我们看看消息的生产与消费,以及broker横向扩容

producer生产消息:

  • 消息发送时,会默认以轮询queue列表的方式,往对应broker上对应queue中发送消息。在本例中,如果生产者S发送了五条topic为topicA的消息,其中会有两条消息进入broker1,三条消息进入broker2,broker1与broker2的权重比为2:3。写队列数可以在broker的配置文件中进行配置,实际生产中我们可以根据机器配置来决定该配置项的比重。
  • 如果消息生产速度过快,导致broker负载过高,可以向现有的broker集群中增加master broker,consumeQueue列表会对应变化,比如新增的为broker3,写队列数配置为5,那此时consumeQueue的数量就增加了5个,新的权重比就是2:3:5,broekr1和broker2的压力就降低了一半左右,实现了broker的横向扩容

consumer消费消息:在介绍consumer前,需要搞清楚这几个概念

  • group:消费者启动时,需要指定一个groupId,使用相同groupId的消费者属于同一个group。同一个group下的消费者消费逻辑必须完全一致(包括Tag的使用)。
  • 集群消费:当使用集群消费模式时,每条消息只会被集群内的一个消费者处理。
  • 广播消费:当使用广播消费模式时,每条消息都会被集群内的所有消费者处理

集群消费是更普遍的模式,举个简单场景,orderService服务发布了一条订单生成的消息,goodsService服务订阅该消息扣减库存,无论goodsService部署了多少台实例(实例数=消费者数),你肯定希望只扣减一次库存

下面就重点介绍集群消费模式的工作原理,consumer消费消息时,需要算出自己应该负责消费topic下哪些queue中的消息,会从任意一台broker上查询与自己处于同一个消费者组的所有消费者ID,然后按平均分配的策略算出自己应该负责的queue列表

平均分配是关键,当consumer的数量发生变化(新增机器,上线下线),broker会向所有consumer发起通知,消费者会重新计算自己负责的queue,以达到实时均衡。所以如果消费速度跟不上,新增机器就可以立即分摊一部分消息,实现消费能力的横向扩展

在算出自己负责的queue列表之后,还需要知道当前应该从queue的哪个位置开始消费(也就是offset),集群消费模式下由broker控制offset

broker在内存中维护offset值,并且,后台会有定时任务(5S一次),将offset刷入磁盘,磁盘内容为json格式,如下:topic_1@CID_1表示topic_1下的消费者组CID_1,0:24表示queueId为0的queue已消费到24的位置

消费者新加入消费时,从broker上查询最近offset开始消费,broker在处理消息拉取后,会返回下一个该消费的位置:nextoffset,消费者拿到返回信息后,会基于nextoffset发起下一次的拉取,如果nextoffset并没有变大,说明这个queue里当前没有可消费的消息。

 

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值