名词
每一个messageQueue都有下面三个东西
brokerOffset
每个broker中的queue在收到消息时会记录offset,初始值为0,每记录一条消息offset会递增+1,
consumerOffset
消费者消费进度/位置
diffTotal
Offset-consumerOffset=diffTotal消费积压/未被消费的消息数量
消费者
DefaultMQPushConsumer 与 DefaultMQPullConsumer
在消费端,我们可以视情况来控制消费过程
DefaultMQPushConsumer 由系统自动控制过程,
DefaultMQPullConsumer 大部分功能需要手动控制
集群消息的消费负载均衡
在集群消费模式下(clustering)
相同的group中的每个消费者只消费topic中的一部分内容
group中的所有消费者都参与消费过程,每个消费者消费的内容不重复,从而达到负载均衡的效果。
使用DefaultMQPushConsumer,新启动的消费者自动参与负载均衡。
ProcessQueue
消息处理类
RocketMQ消息推送原理
consumer与broker采用长轮询方式获取消息
短轮询:
client发送一个请求,server接受之后处理,无论客户端想要的东西有没有,都会立即返回,客户端可能收到空的,也可能收到有数据的,客户端得到服务器反馈之后,会断开连接,
好处:服务器不需要维护客户端的连接
坏处:客户端会发送太多无用的请求
长连接:
client发送连接请求,服务器收到并且维持连接,有数据就推给客户端
好处:数据推送即使
坏处:服务器需要维护连接,开销大
长轮询:
跟短轮询差不多, 差别就在 当服务器没有客户端想要的数据时,会挂起该连接,等到有数据了,在推送数据给客户端
rocketMQ中的broker服务器就是用的这种推送模式,这种模式跟短轮询比肯定是要好一点的,
但是为什么不用长连接,及时推送消息呢,主要原因在于RocketMQ是消息中间件,他不知道客户端的消费能力,推多了 消费端就撑死了,推少了有感觉没有最大利用消费者能力,所以由消费者自己决定他什么时候可以消费
1 | DefaultMQPullConsumer |
源码
MQAdmin
1 | MQAdmin |
MQConsumer
1 |
|
ClientConfig
1 | ClientConfig |
客户端消费流程
1 | public static void main(String[] args) throws MQClientException { |
启动:
1 | if (null == this.clientConfig.getNamesrvAddr()) { |
- 本文作者: 忘忧症
- 本文链接: https://NepenthesZGW.github.io/2020/06/17/framework/RocketMQ/RocketMQ原理/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!