这篇文章主要介绍了RocketMQ客户端PUSH消费中并发消费与顺序消费的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。
创新互联长期为近千家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为青川企业提供专业的做网站、网站建设,青川网站改版等技术服务。拥有10年丰富建站经验和众多成功案例,为您定制开发。
小结:PullMessageService处理拉取消息请求。通过组织RequetHeader需要包含从哪里开始拉取(ConsumerGroup、Topic,Queue,queueOffset)等信息,向Broker发起请求,取回消息后对消息进行处理。当该Queue的消息数量超过1000,或者最小与最大偏移量之间的差距超过默认2000也会触发限流,即:延迟50毫秒放入请求队列。也可以通过挂起消费线程来延迟(1秒)消息拉取,从而达到消费限流作用。
小结:PullMessageService处理消息部分流程:将消息提交给了processQueue红黑树缓存;同时将消息提交给consumeMessageService来处理具体的消息内容。
小结:ConsumeMessageService并发消费(ConsumeMessageConcurrentlyService)主要工作交给Listener(客户端传入)进行处理,并对处理结果进行统计和处理;对于失败消息,广播消费会丢弃,集群消费会发回Broker重新消费;清理ProcessQueue并更新缓存(offsetTable)消费进度。
小结:顺序消费流程跟并发消费最大的区别在于,对要处理的队列加锁,确保同一队列,同一时间,只允许一个消费线程处理。
1.为什么顺序消费时需要对Broker发请求对要处理的队列加锁?
2.对Broker端队列加锁流程是怎么样的?
3.既然加锁了需要解锁吗?
4.会存在Broker加锁过期了客户端还在处理该队列的情况吗?
小结:顺序消费时对Broker端队列加锁防止该队列在特定时间内(一次默认60秒)被分配给其他clientId处理;Broker端加锁了,一次加锁失效时长为60秒;不存在Broker加锁过期了客户端还在处理该队列的情况,Broker加锁时长为60秒,而客户端加锁时长为30秒,当客户端加锁时长失效时会重新请求Broker加锁并更新时间戳,从而可以持续延长加锁时间。
感谢你能够认真阅读完这篇文章,希望小编分享的“RocketMQ客户端PUSH消费中并发消费与顺序消费的示例分析”这篇文章对大家有帮助,同时也希望大家多多支持创新互联,关注创新互联行业资讯频道,更多相关知识等着你来学习!