consumer

最新推荐文章于 2022-10-22 11:53:48 发布

kobexzf

最新推荐文章于 2022-10-22 11:53:48 发布

阅读量122

点赞数

分类专栏： # rocketmq

本文链接：https://blog.csdn.net/kobexzf/article/details/114014024

版权

rocketmq 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

同一consumerGroup的各consumer订阅关系必须一致，否则互相覆盖

pull通过registeredTopics和pull设置订阅关系，push通过subsrcibe和setSubscriptions设置订阅关系

rebalance：

按照topic进行rebalance，通过含topic数据的任一broker获取所有consumer，通过ns获取所有队列，按照某种算法进行分配，若为广播那就是所有队列都可以分配，

新增了队列获取位点创建pullRequest进行拉取，顺序消费还需要lock新增队列，若为pull则不拉取，不过pull可以通过MessageQueueListener监听分配到队列的变化，减少了队列做好清理工作并同步位点到远端

问题：分配算法各consumer自己设置，rebalance时机各consumer自己把握，这种没有统一协调的分配感觉不靠谱

启动：push+集群模式会订阅自己的retry topic，push根据MessageListener决定是否顺序消费，生成并启动ConsumeMessageService

pull是用户指定队列和偏移进行拉取

push：根据消息数量，大小，非顺序消费下最大span进行流控，顺序消费需确保锁定，首次消费会重新从远端同步位点，集群模式下若向master拉取，那么同时也会提交位点

根据broker给出的建议到某broker拉取（首次master拉取），若为classFilter模式选一filterSrv拉取，拉取获得队列的最大最小偏移，下次拉取的偏移，建议的broker

消息进行tag过滤，放入ProcessQueue，提交给ConsumeMessageService

ConsumeMessageService

并发模式：按处理批次拆分放入内部线程池，reject则过会再放入

retry message恢复原始topic，listener处理，注意可以设置context内的ackIndex表明消费成功的消息下标，全部失败是-1，result如果是RECONSUME_LATER也表明全部失败

集群模式下对消费失败的消息： sendback或直接往延迟队列(3+reconsume次数)+retry topic发或等会在本地重新消费

sendback：发回master，context内delayLevel<0或reconsume次数达到上限直接入死信，其余入延迟队列+retry topic，delayLevel>0 不变，delayLevel=0则设置为3+reconsume次数

最后ProcessQueue移除消息且本地位点更新(除非本地重新消费，否则都认为处理完毕需更新位点)

顺序模式：

一个队列在一个consumerGroup下只能被一个clientId锁定，独占，可重入，会过期，过期则其他clientId可抢占，锁信息(包括锁定时间)在master上和消费此队列的consumer上都会体现

锁定是集群模式下的操作，广播模式不锁定

周期性锁定rebalance获取的所有队列，rebalance到某队列会立即lock（这里没有判断集群模式，可能bug），lock失败则忽略此队列，消费过程中发现未lock或lock过期也会去lock

rebalance不再消费某队列会unlock，shutdown时会unlock所有队列

一个队列一般只有一个任务，这个任务会在持有队列锁(保证线程独占，一般没有竞争)时不断从ProcessQueue获取消息进行处理，即便在未锁定/锁过期/连续消费太久/result表明需suspend时，也会在任务结束时提交个新任务过会执行，只有无法从ProcessQueue获取消息时，才会自然结束，此时拉取才会添加新任务进来

根据context的autoCommit和result决定是否本地位点提交，是否需要将消息放回ProcessQueue进行重新消费等

broker侧逻辑

若commitLog最大位置-拉取的commitLog位置>总内存的40%(堆积)，建议从slave拉取

slave不可读，走master，slave可读且建议从slave拉取(whichBrokerWhenConsumeSlowly)，slave可读但并未建议从slave拉取（brokerId）

MessageFilter（根据是否支持重试选用不同实现），主要用于tag过滤(ConsumeQueue里tag的hashcode匹配)，属性过滤(通过sql表达式判断消息属性)

若subscriptionFlag则使用客户端带来的订阅过滤数据，否则使用broker侧保存的订阅过滤数据

broker侧根据配置选择传输byte数组还是FileRegion

若拉取不到数据，客户端表明可以suspend且带来了longPollingTimeout(若broker不支持long poll，则timeout改成broker侧的shortPollTimeout)，则请求可以suspend

pull 不提交位点，可suspend可不suspend，含subscriptionFlag，非classFilter

push 集群且master提交位点，suspend，根据配置决定subscriptionFlag，根据具体情况决定classFilter

位点

集群模式位点在broker，广播模式位点在客户端本地