RocketMQ实战-初探PushConsumer限流机制实现原理

PushConsumer消费模型

客户端实现消息拉取简易的模型，右侧是消息拉取涉及的类以及用数字标识的拉取流程，左侧代表最初的PullRequest是如何构建出来的。

我们了解到，在RocketMQ中，虽然消息消费被命名为了Push，但是本质上还是拉的模型，只不过这个拉取的动作被封装到了客户端API的内部，在使用者看来，消息是源源不断的被Push了过来。

消费端限流机制

PullMessageService这个线程类负责源源不断的拉取消息供客户端线程池消费，并且将拉取下来的消息存储在ProcessQueue中。

一个MessageQueue可以理解为一个服务端的队列，一个ProcessQueue可以理解为服务端的队列在客户端的虚拟镜像，ProcessQueue有两个属性和一个方法，跟客户端限流息息相关。

如果线程池消费的速度跟不上拉取的速度，并且不加以控制的话，消费者内部持有的线程池中的任务队列积攒的任务就会越来越多，容易造成内容溢出等异常情况，为了加以限制，保障客户端稳定的运行，RocketMQ客户端实现了三个维度的限流机制。

积压的消息个数限流

如果ProcessQueue中