springcloud RocketMQ ，一个mq消息发送后，客户端是怎么一步步拿到消息去消费的？我们要从代码层面探究这个问题。
找的流程图，有待考究。
以下我们开始debug：
拉取数据的线程：
PullMessageService.java 本质是一个线程类
public class PullMessageService extends ServiceThread {private final LinkedBlockingQueue<PullRequest> pullRequestQueue = new LinkedBlockingQueue<PullRequest>();// ..
}
执行逻辑，一直循环拿取阻塞队列的内容，阻塞队列的内容由负载均衡服务提供。（阻塞队列中保存了目前客户端占有的 brokder - queue 信息）
然后进入 DefaultMQPushConsumerImpl.java 的 pullMessage（关键）
这里面有个关键的方法，this.pullAPIWrapper.pullKernelImpl(…) 这里传入了成功回调 pullCallback。
一直执行到 pullMessageAsync 是异步拉取消息，成功后会执行回调。
成功后的回调逻辑：
ConsumeMessageConcurrentlyService.java 的 submitConsumeRequest 方法，将任务下发给消费者线程池 consumeExecutor （ThreadPoolExecutor 类型）去执行。（日志显示就是这里执行的消费业务）
~~
ok，我们看看开启的这个线程做了什么。
首先，单独一个线程是无法debug跨线程的，所以我们继续在 ConsumeMessageConcurrentlyService.ConsumeRequest 消费者请求线程中debug run方法，看看是怎么执行到我们的业务逻辑的。
发现是 监听器 listener 的消费逻辑
这个 listener 是一个接口，而且这个接口没有找到代码impl，也就是可能是匿名的视线
我们debug直接跳到了 RocketMQInboundChannelAdapter.java 的监听器，当时就是从这里把监听器注册进来的。
匿名方法执行了 RocketMQInboundChannelAdapter.this.consumeMessage
执行了一段 retry 逻辑（spring的重试框架），里面执行了发送消息逻辑。
发现底层用的是 spring 的 integration 消息通信框架！
debug进去send逻辑，会发送到一个 channel 中去
channel 里就有我们的处理方法的代理对象，是转发 dispatcher 的目标处理器 handlers 之一。
后面不出所料，就是通过反射去执行这个方法。
然后就跑到了我们的逻辑：
创作不易，希望点赞、收藏、关注支持~