Consumer
consumer pull message
订阅
在Consumer启动之前先将自己放到一个本地的集合中,再以后获取消费者的时候会用到,同时会将自己订阅的信息告诉broker
接收消息
consumer启动的时候会启动两个service:
RebalanceService:主要实现consumer的负载均衡,但是并不会直接发送获取消息的请求,而是构造request之后放到PullMessageService中,等待PullMessageService的线程取出执行
PullMessageService:主要负责从broker获取message,包含一个需要获取消息的请求队列(是阻塞的),并不断依次从队列中取出请求向broker send Request
执行时序图太大,截屏截不全,所以放在git上,在这里:RocketMQ.asta
从Broker pullMessage
在PullMessageService中通过netty发送pull消息的请求之后,Broker的remoteServer会收到request,然后在PullMessageProcessor中的processRequest处理,先会解析requestHeader,request中带了读取MessageStore的参数:
- consumerGroup
- topic
- queueId
- queueOffset
- MaxMsgNums
- subscriptionData(ConsumerManager中获取)
processRequest处理流程
- 判断Broker当前是否允许接收消息
- 找到subscriptionGroupConfig,subscriptionGroupTable,如果不存在当前的group则新增一个
- 是否subscriptionGroupConfig.consumeEnable
- 获取从TopicConfigManager.topicConfigTable获取topicConfig
- topicConfig是否有读权限
- 校验queueId是否在范围内
- ConsumerManager.getConsumerGroupInfo获取ConsumerGroupInfo
- consumerGroupInfo.findSubscriptionData查找subscriptionData
- MessageStore.getMessage读取消息,从文件中读取消息,属于pullMessage的核心方法
- 判断brokerRole,master和slave工作模式的哪一种
- 判断MessageResult.status
- 如果responseCode是SUSCESS,判断是使用heap还是非heap方式传输数据