Topic有多个message queue，消息可以并行的向各个message queue发送，消费者也可以并行的从多个message queue读取消息并消费
clustering模式消费一个topic里的消息内容是哦，可以启动多个消费者并行消费，每个消费者只消费Topic里消息的一部分，以此提高消费速度，这个时候就是通过订阅组来指明哪些消费者是同一组，同一组的消费者共同消费同一个Topic里的内容
DefaultMQPushConsumer由系统控制读取操作，收到消息后自动调用传入的处理方法来处理；
DefaultMQPullConsumer读取操作中的大部分功能由使用者自主控制
RocketMQ支持两种消息模式，clustering和broadcasting
集群模式下，同一个consumergroup里的每个consumer只消费所订阅消息的一部分内容，同一个consumergroup里的所有的comsumer消费的内容合起来才是所订阅topic内容的整体，从而达到负载均衡的目的
广播模式下，同一个consumergroup里的每个consumer都能消费到所订阅topic的全部消息，也就是一个消息会被多次分发，被多个consumer消费
可以指定消费某个Topic下的多个标记了某tag的消息，也可以消费全部
Push方式是服务端接收到消息后，主动把消息推送给客户端，实时性高，但弊端是加大了服务端工作量，而且无法顾及到客户端处理能力的不同，造成潜在问题
Pull的方式是客户端循环从服务端拉取消息，主动权在客户端手里，自己拉取到一定的消息后，处理妥当了再接着取，问题是如何设置获取间隔，太短容易浪费忙等，太长可能处理不及时
DefaultMQPushConsuer的源码中有很多PullRequest语句，比如Default-MQPushConsumerImpl.this.executePullRequestImmediately（pullRequest）。为什么“PushConsumer”中使用“PullRequest”呢？这是通过“长轮询”方式达到Push效果的方法，长轮询方式既有Pull的优点，又兼具Push方式的实时性。
服务端接受到请求后，队列里没有新消息，并不急于返回，通过一个循环不断查看状态，每次waitForRunning一段时间，然后再check，默认情况下，当broker一直没有新的消息，第三次check的时候，等待时间超过request里的brokerSuspendMaxTimeMillis,就返回空结果。在等待过程中，如果broker收到了新的消息后悔直接调用notifyMessageArriving函数返回请求结果，长轮询的核心就是，Broker端hold住客户端过来的请求一小段时间，在这个时间内有新的消息到达，就利用现有的连接立即返回给consumer，长轮询的主动权还是掌握在consumer手中，broker即使有大量消息积压也不会主动推送给consumer，缺点就是在Hold过程中需要占用资源，适合在消息队列这种客户端连接数可控的场景