疑问：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：
