RocketMQ之十：RocketMQ消息接收源码.pdfVIP

RocketMQ之⼗：RocketMQ消息接收源码 1.简介 1.1、接收消息 RebalanceService ：均衡消息队列服务，负责通过MQClientInstance分配当前 Consumer 可消费的消息队列( MessageQueue )。当有新 Consumer 的加⼊或移除，都会重新 分配消息队列。 主要实现consumer的负载均衡，但是并不会直接发送获取消息的请求，⽽是构造PullRequest之后放到pullRequestQueue 中，PullMessageService 中，等待 PullMessageService 的线程取出执⾏。 PullMessageService ：拉取消息服务，不断的从 Broker 拉取消息，包含⼀个需要获取消息 pullRequestQueue （是阻塞的），这个队列的由RebalanceService放PullRequest 对象，并不断依次从队列中取出请求向broker send Request。并提交消费任务到 ConsumeMessageService 。只有在PUSH模式下才会使⽤PullMessageService服务线程，该线 程主要是对pullRequestQueue:LinkedBlockingQueuePullRequest 队列进⾏监测，处理该队列中 PullRequest请求对象；当队列⾥有PullRequest对象时，从Broker中拉取消 息，如果队列为空，则阻塞。同时该线程也提供了两种拉取⽅式，分别是⽴即拉取和延迟拉取两种； ConsumeMessageService ：消费消息服务，不断的消费消息，并处理消费结果。 RemoteBrokerOffsetStore:Consumer消费进度管理，负责从 Broker 获取消费进度，同步消费进度到 Broker。 ProcessQueue ：消息处理队列。 MQClientInstance ：是⼀个单例模式，封装对 Namesrv，Broker API调⽤，提供给 Producer、Consumer 使⽤。 RebalanceImpl ：消费端负载均衡的逻辑。该类的调⽤轨迹如下：(MQClientInstance start -- (this.rebalanceService.start()) RebalanceService.run （this.mqClientFactory.doRebalance()） MQConsumerInner.doRebalance(DefaultMQPushConsumerImpl) RebalanceImpl.doRebalance 在这⾥着重说明⼀点：消息队列数量与消费者关系：1个消费者可以消费多个队列，但1个消息队列只会被⼀个消费者消费；如果消费者数量⼤于消息队列数量，则有的消费者会 消费不到消息（集群模式） 1.2、消息消费 pull和push⽅式： 对于任何⼀款消息中间件⽽⾔，消费者客户端⼀般有两种⽅式从消息中间件获取消息并消费： （1）Push⽅式：由消息中间件（MQ消息服务器代理）主动地将消息推送给消费者；采⽤Push⽅式，可以尽可能实时地将消息发送给消费者进⾏消费。但是，在消费者的处理 消息的能⼒较弱的时候(⽐如，消费者端的业务系统处理⼀条消息的流程⽐较复杂，其中的调⽤链路⽐较多导致消费时间⽐较久。概括起来地说就是“慢消费问题”)，⽽MQ不断地 向消费者Push消息，消费者端的缓冲区可能会溢出，导致异常； （2）Pull⽅式：由消费者客户端主动向消息中间件（MQ消息服务器代理）拉取消息；采⽤Pull⽅式，如何设置Pull消息的频率需要重点去考虑，举个例⼦来说，可能1分钟内连 续来了1000条消息，然后2⼩时内没有新消息产⽣（概括起来说就是“消息延迟与忙等待”）。如果每次Pull的时间间隔⽐较久，会增加消息的延迟，即消息到达消费者的时间加 长，MQ中消息的堆积量变⼤；若每次Pull的时间间隔较短，但是在⼀段时间内MQ中并没有任何消息可以消费，那么会产⽣很多⽆效 Pull请求 RPC开销，影响MQ整体的⽹络 性能； 从严格意义上说，RocketMQ并没有实现真正的消息消费 Push模式，⽽是对Pull模式进⾏了⼀定的优化， ⼀⽅⾯在Consumer端开启后台独⽴的线程—PullMessageService 不断地从阻塞队列—pullRequestQueue 中获取PullRequest请求并通过⽹络通信模块发送Pull消息 RPC请求 给Broker端。 另外⼀⽅⾯，consumer端后台还有另外⼀个独⽴线程—Reb