在rocketmq中，对于消费者而言，有两种模式，push和pull

我在没有看源码之前，看其他博客的时候，大部分的说法是：

mq中有两种获取消息的模式，一种是push，一种是pull；pull这种模式是消费者自己去拉取消息，根据自己的消费能力去拉取；而push模式是mq接收到消息之后，会推送给consumer

去翻了下官网的文档，确实也是这么说的
rocketmq官方文档

但是这里要看怎么去理解，根据看源码，如果我们在源码层面上去看，不管是pull模式还是push模式，都是consumer自己去broker拉取消息的，并且从源码上也可以证明（我这里并没有说服务端和客户端，而是consumer和broker）

因为站在broke的角度去考虑，broker为什么需要关心consumer是pull模式还是push模式呢？按照网上大部分的说法，对于push模式是broker自己推送消息给consumer，如果这个推断成立，那broker设计我认为是有问题的，因为对于broker而言，我只是去存储消息的，我不关心你是push还是pull，我只需要提供接口，让client来查询消息就可以了，如果broker还需要关心consumer的模式，那系统就太耦合了；所以这个说法一定是不成立的（一定不是broker主动推送消息给consumer）

但是官方上说的是服务端和客户端，所以要看怎么理解服务端和客户端的概念：
如果我们认为client、broker、nameSrv这几个组件组成的mq是服务端，而业务系统是客户端，那这个说法确实也没有问题。因为对于push模式，如果作为业务系统来说，就是被动的，被mq调度的，当消息拉取到之后，会调用业务系统注册的messageListener方法，此时对于业务系统来说，主需要被动的等待被调用就可以了

但是，如果说服务端和客户端指的是nettyServer和nettyClient，那这个说法就不对了
如果有看过前面两篇拉取消息push和pull模式的博客，我们会发现，对于pull和push模式，大致的逻辑是这样的：

所以总结来看，如果站在业务系统和rocketmq的角度来看，push模式确实是mq主动把消息推送给业务系统的；pull模式是业务系统根据自己的消费能力，去拉取消息

但是实际上，我们把rocketmq这个框架，掰开，仔细去看的话，

对于consumer来说，有push和poll模式，
对于push模式，是client通过netty请求去broker拉取消息，拉取到消息之后，去回调业务上注册的messageListener方法执行，只是在回调注册的messageListener方法的时候，分为了顺序消费和并行消费，所谓的并行消费，就是同时有多个线程去处理消息，回调messageListener

对于pull模式，是通过netty请求去broker拉取消息，拉取到消息之后，将消息存入到了内存中的一个队列中，存入到队里中之后，立即发起下次请求；而消费者会调用queue.poll()方法，如果queue中没有消息，就返回空，当消息被写入到queue中之后，消费者会立即执行；对于pull模式来说，消息是堆积在了queue中，各个消费者按照自己的消费能力，去queue中消费消息

所以，对于官网上的这个说法，我们要明白什么是服务端什么是客户端