浅谈长轮询及源码解析 RocketMQ 长轮询是如何实现的？
[TOC]
一、长轮询
1.1、常规轮询
从服务器获取新信息的最简单的方式是定期轮询。也就是说，定期向服务器发出请求：“你好，我在这儿，你有关于我的任何信息吗？”例如，每 10 秒一次。
作为响应，服务器首先通知自己，客户端处于在线状态，然后 —— 发送目前为止的消息包。
这可行，但是也有些缺点：
- 消息传递的延迟最多为 10 秒（两个请求之间）。
- 即使没有消息，服务器也会每隔 10 秒被请求轰炸一次，即使用户切换到其他地方或者处于休眠状态，也是如此。就性能而言，这是一个很大的负担。
因此，如果我们讨论的是一个非常小的服务，那么这种方式可能可行，但总的来说，它需要改进。
1.2、长轮询
长轮询为了解决短轮询存在的问题，客户端发起长轮询，如果服务端的数据没有发生变更，会hold住请求，直到服务端的数据发生变化，或者等待一定时间超时才会返回。返回后，客户端再发起下一次长轮询请求监听。
下面借用图片来说明一下流程：
- 请求发送到服务器。
- 服务器在有消息之前不会关闭连接。
- 当消息出现时 —— 服务器将对其请求作出响应。
- 浏览器立即发出一个新的请求。
这样设计的好处：
- 相对于低延时，客户端发起长轮询，服务端感知到数据发生变更后，能立刻返回响应给客户端。
- 服务端的压力减小，客户端发起长轮询，如果数据没有发生变更，服务端会hold住此次客户端的请求，hold住请求的时间一般会设置到30s或者60s，并且服务端hold住请求不会消耗太多服务端的资源。
1.3、长轮询如何解决了什么？
- 当没有消息可拉取时，长轮询会将本次请求挂起，然后由
broker主动push消息给consumer。这样就避免了大量无效的请求。 - 长轮询不会以固定的频率请求，而是在收到响应后，才会继续请求。
二、MQ消费方式
消费方式就是指消费者如何从MQ中获取到消息，分为两种方式，push（推方式）和pull（拉方式）。
2.1、push（推方式）
push，顾名思义，就是推的意思。就是当MQ收到生产者产生的消息的时候，会主动将消息推送到消费者进行消费，这种模式就叫push，也就是MQ将消息推给到消费者的意思。
push这种模式的好处就是响应快，消息的实时性比较高，一旦消息MQ收到消息，那么就能立马将消息推送给消费者，消费者也就能立马收到消息进行消费。
但是这种push的模式，有个缺点就是一旦消息量比较大时，对消费者性能要求比较高，因为是消费者无法控制MQ消息的推送速度，一旦消息量大，那么消费者消费消息的压力就比较大。
2.2、pull（拉方式）
push是MQ主动给消费者推消息，那么pull呢？刚好跟push相反，就是消费者主动去MQ中拉取消息。
那么pull的优缺点自然也就跟push刚好相反。因为是消费者主动去MQ中拉取消息，那么消费者可根据自身消费的情况，决定何时去拉取消息，主动权在自己手上，这样消费者的压力就会相对小点；但是缺点也很明显，那么就会实时性相对于push方式会低一些，因为你得决定拉的时间间隔。
其实想想，消费方式就跟拿快递一样，快递就是一个消息，我自己就是消费者，快递要么快递小哥主动送（push）到家，要么我自己去快递站拿（pull）。
2.3、RocketMQ对于消费方式的实现
这两种方式都有各自的缺点：
- 拉取：拉取的间隔不好确定，间隔太短没消息时会造成带宽浪费，间隔太长又会造成消息不能及时被消费
- 推送：「推送和速率难以适配消费速率」，推的太快，消费者消费不过来怎么办？推的太慢消息不能及时被消费
然后就有大佬把拉取模式改了一下，即不会造成带宽浪费，也能基于消费的速率来决定拉取的频率！
其实很简单，Consumer发送拉取请求到Broker端，如果Broker有数据则返回，Consumer端再次拉取。如果Broker端没有数据，不立即返回，而是等待一段时间（例如5s）。
- 如果在等待的这段时间，有要拉取的消息，则将消息返回，Consumer端再次拉取。
- 如果等待超时，也会直接返回，不会将这个请求一直hold住，Consumer端再次拉取
三、RocketMQ 消费端的长轮询实现
3.1、概要流程
消费者消费流程图如下：
- Consumer 发送拉取消息请求；
- 判断有没有过多消息没有消费，如果有的话，那么就间隔一定时间再次从①开始执行拉取消息的逻辑；
- Broker 收到请求后如果能够拉取消息，那么将拉取到的消息直接返回；
- 如果没有拉取到消息，那么根据 Broker 是否支持挂起和是否开启长轮询来判断是否要进行轮询以及进行哪种轮询。
- 如果支持挂起，那么会将该拉取请求挂起
- 长轮询等待 5s
- 短轮询等待 1s
- 检查消费队列中是否有新消息到达，如果没有则继续等待，以此循环。如果有新消息，处理挂起的拉取消息请求并返回消费者。
- 如果没有新消息到达，轮询后会检查每个挂起的拉取请求的挂起时间是否超过挂起时间阈值，如果超过那么也会直接返回消费者，否则继续循环进行轮询操作。
那么按照上述流程，开启长轮询的情况下，如果一次轮询没有找到消息，要等待 5s 才能进行下一次查询。如果这 5s 当中有新的消息存入，如何保证能够立刻消费到？
解决方案不难想到，就是新的消息写入后，主动进行通知，让挂起的拉取请求立刻进行拉取操作。
RocketMQ 就是这么做的，在消息存入 CommitLog 后的 doReput 方法中，会判断是否是长轮询，如果是则会发送一个通知，让挂起的拉取请求立刻进行处理。
3.2、消费者拉取消息控制压力源码
当消费者准备去拉消息的时候，会先去判断当前消费者消费的压力再决定是否去拉取消息。
RocketMQ提供了两种判断消费压力逻辑，一种是基于还未消费的消息的数量的大小，还有一种是基于还未消费的消息所占内存的大小。
控制压力源码
- 判断还未消费消息的数量，数量太多就等会再执行重新执行拉取消息的逻辑
- 判断还未消费消息的大小，如果还未消息的消息占用的内存过大，就等会再执行重新执行拉取消息的逻辑
总的一句话就是，当消费者消费的压力过大时，就不会去拉取消息，而是等待一定的时间再去执行拉取消息的逻辑，如果压力还是很大，就还继续等，如此循环，直到消费者的消费压力小于阈值的时候，才会真正的发送请求到MQ中拉取消息。
3.3、MQ将请求hold住
当服务端未找到消息时，就将请求进行挂起，存起来
请求hold住源码
拉取不到消息时，会调用PullRequestHoldService的suspendPullRequest方法讲请求存储起来。PullRequestHoldService是用来存储拉取请求的类。
PullRequestHoldService
suspendPullRequest方法会将请求分类，放到ManyPullRequest里，然后用一个ConcurrentHashMap进行存储
3.4、MQ收到消息回调给消费者
NotifyMessageArrivingListener
当生产者发送的消息达到MQ的时候，MQ会回调NotifyMessageArrivingListener的arriving方法，之后就会调用PullRequestHoldService的notifyMessageArriving方法，MQ会重新处理拉取消息的逻辑，此时就能找到最新来的那条消息，从而将最新的消息通过网络返回给消费者。
notifyMessageArriving和返回消息逻辑
四、更深层次源码分析
参考资料：
