RocketMQ（三）：消费者API核心使用

PushConsumer核心参数详解

• consumerFromWhere：表示消费者从哪个位置开始消费
• allocateMessageQueueStrategy：消息分配策略，集群模式下使用，集群模式下平均分配给所有客户端
• subscription：订阅
• offsetStore：存储实际的偏移量
• consumeThreadMin/consumeThreadMax：线程池的自动调整配置项，调整消费端的线程池，辅助consumer的消费
• consumeConcurrentlyMaxSpan/pullThresholdForQueue：流控，第一个表示单个队列并行跨度是多少，第二个表示一个队列最大的消息个数是多少
• pullinterval/pullBatchSize：Pull模式消息拉取，第一个主要是消息拉取的时间间隔，第二个是一次拉取多少条数据
• consumerMessageBatchMaxSize：默认1，表示一次拉取多少条数据

PushConsumer消费模式-集群模式

• Clustering模式（默认）
• GroupName用于把多个Consumer组织到一起
• 相同GroupName的Consumer只消费所订阅消息的一部分，目的是达到天然的负载均衡机制

PushConsumer消费模式-广播模式

• Broadcasting模式（广播模式）
• 同一个ConsumerGroup里的Consumer都消费订阅Topic全部信息，也就是一条消息会被每一个Consumer消费
• setMessageModel方法

消息存储核心-偏移量Offset

• Offset是消息消费进度的核心
• Offset指某个topic下的一条消息在某个MessageQueue里的位置
• 通过Offset可以进行定位到这条消息
• Offset的存储实现分为远程文件类型和本地文件类型两种，下面解析这两种模式

集群模式-RemoteBrokerOffsetStore解析

• 默认集群模式Clustering，采用远程文件存储Offset
• 本质上因为多消费模式，每个Consumer消费所订阅主题的一部分
• 这种情况需要Broker控制offset的值，使用RemoteBrokerOffsetStore

广播模式-LocalFileOffsetStore解析

• 广播模式下，由于每个Consumer都会收到消息且消费
• 各个Consumer之间没有任何干扰，独立线程消费
• 所以使用LocalFileOffsetStore，也就是把Offset存储到本地

消费者长轮询模式分析

• DefaultPushConsumer是使用长轮询模式进行实现的
• 通常主流消息获取模式：Push消息推送模式 & Pull消息拉取模式
• Push消息推送模式：Broker端主动把消息推送到消费端消费，这种方式有很多弊端，首先加大了Broker的工作量，需要Broker额外的线程和消费端交互；其次Client端处理能力不同，有的高有的低，有的处理能力就不行了，所以对于Broker来说它推消息是不可控的，比如说Client消费过慢的话会出现消息堆积，导致内存溢出，这就是消息推的机制。
• Pull消息拉取模式：主动权掌握在Consumer手里，Client端可以根据自己的消费能力消费多少拉多少，但是也会有问题，比如每次拉取消息的时间间隔问题，比如队列一小时一条消息，但是拉取时间一分钟拉一次，基本上绝大部分时间的拉取都是没有意义的；另一方面，拉取时间过长会导致消息没有办法第一时间处理。
• 长轮询机制：RocketMQ既不是采用Push也不是Pull的机制，它采用的是长轮询的机制；其实也是消费者向Broker去发起请求，它和Pull不一样，把请求发给Broker之后，Broker不让请求直接响应，它会做一个长时间的阻塞，默认阻塞时间是15s，如果有消息的话直接返回，没有消息就会阻塞等待。

RocketMQ消费者-PullConsumer使用

• 消息拉取方式：DefaultMQPullConsumer
• Pull方式主要做了三件事情：
  • 获取Message Queue并遍历
  • 维护OffsetStore
  • 根据不同的消息状态作不同的处理