【mq读书笔记】消息拉取

疑问：PullRequest何时添加？

PullMessageService提供延迟添加与立即添加2种方式

疑问：PullRequest是在什么时候创建的呢？

1.上上图中 PullRequest pullRequest = this.pullRequestQueue.take(); this.pullMessage(pullRequest);mq根据PullRequest拉取任务执行完一次消息拉取任务之后，又将PullRequest对象放入到pullRequestQueue，第二个是在RebalancceImpl中创建。

PullMessageService只有在拿到PullRequest对象时才会执行拉取任务，看一下PullRequest的属性：

看下this.pullMessage的实现：

ProcessQueue实现机制：

ProcessQueue是MessageQueue在消费端的重现，快照。PullMessageService从消息服务器默认每次拉取32条消息，按消息的队列偏移量顺序存放在ProcessQueue中，PullMessageService之后将消息提交到消费者消费线程池，消息成功消费后从ProcessQueue中移除。

消息拉取基本流程

1.消息拉取客户端消息拉取请求封装

2.消息服务器查找并返回消息

3.消息拉取客户端处理返回的消息

入口：DefaultMQPushConsumerImpl#pullMessage.

队列被丢弃，消费者被挂起，将拉取任务延迟1s再次放入到拉取任务队列中。

消息拉取流控，从消息消费数量与消费间隔两个维度进行控制。

顺序消息没有拿到锁不能进行消费

拉取该主题订阅信息，如果为空，结束本次消息拉取，关于该队列的下一次拉取任务延迟3s。

构建消息拉取系统标记：

调用pullAPIWrapper.pullKernelImpl方法与服务端交互，调用pullKernelImpl方法之前先了解一下其参数含义。

mq：从哪个消息消费队列拉取消息。

subExpression：消息过滤表达式。

expressionType：消息表达式类型

offset：消息拉取偏移量

maxNums：本次拉取最大消息条数，默认32条

sysFlag：拉取系统标记

commitOffset：当前MessageQueue的消费进度（内存中）

brokerSuspendMaxTimeMillis：消息拉取过程中允许Broker挂起时间。默认15秒

timeoutMills：消息拉取超时时间。

communicationMode：消息拉取模式，默认为异步拉取

pullCallback：从Broker拉取到消息后的回调方法。

根据brokerName,BrokerId从MQClientInstance中获取Broker地址，在整个MQ Broker的部署结构中，相同名称的Broker构成主从结构，其BrokerId会不一样，在每次拉取消息后，会给出一个建议，下次拉取从主节点还是从节点拉取。

如果消息过滤模式为类过滤，则需要根据主题名称，broker地址找到注册在Broker上的FilterServer地址，从FilterServer上拉取消息，否则从Broker上拉取消息。

根据RequestCode.PULL_MESSAGE找到Broker端处理消息拉取的入口：

PullMessageProcessor#processRequest:

1.根据订阅信息，构建消息过滤器。

2.调用MessageStore.getMessage查找消息：

根据主题名称与队列编号获取消息消费队列。

消息偏移量异常情况下校对下一次拉取偏移量

根据消息队列偏移量从commitlog文件中查找消息。

根据PullResult填充ResponseHeader的nextBegainOffset，minOffset，maxOffset。

根据主从同步延迟，如果从节点数据包含下一次拉取的偏移量，设置下一次拉取任务的brokerId：

根据GetMessageResult编码转化成response。

如果commitlog标记可用并且当前节点为主节点，则更新消息消费进度。

最后整理一下返回结果的枚举：

在getMessgae之前的校验逻辑会返回下面这些code：

在getMessage之后会拿到getMessageStatus：

最后一getMessageStatus会转化成：

当最后的response返回给客户端的时候客户端是这么处理的：

下面内容详情见：https://www.cnblogs.com/lccsblog/p/12249265.html

同步消费：

除了下面几种其他直接抛出了异常：

异步消费：

也是先进行上面的过程，然后进行了回调：

最后再看下消息拉去之后的回调：

再看下callback：

可以看到除了FOUND之外NO_MATCHED_MSG和NO_NEW_MSG都会进行重试，OFFSET_ILLEGAL则drop了消费队列，继续看下FOUND：

下面内容，详情见：https://www.cnblogs.com/lccsblog/p/12262334.html

最终会回调我们创建consumer的时候注册的listener。

看下我们在listener中的返回会影响什么：

先是兼容了返回为空和超时的情况。

看下最后的processConsumeResult：