
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源
去关联
2.1 消息拉取流程中的关键设计
客户端向服务端拉取消息,连续1000W条消息都不符合条件,一次过滤查找这么多消息,肯定非常耗时,客户端也不能等待这么久,那服务端必须采取措施,必须触发一个停止查找的条件并向客户端返回NO_MESSAGE,客户端在消息查找时会等待多久呢?
核心关键点一:客户端在向服务端发起消息拉取请求时会设置超时时间,代码如下所示:
其中与超时时间相关的两个变量,其含义分别:
核心关键点二:Broker端在处理消息拉取时设置了完备的退出条件,具体由DefaultMessageStore的getMessage方法事项,具体代码如下所述:
核心要点:
回到这个问题,如果服务端连续1000W条非tag1的消息,拉取请求不会一次性筛选,而是会返回,不至于让客户端超时。
从这里可以打消第一个顾虑:服务端在没有找到消息时不会傻傻等待不返回,接下来看是否会有积压的关键是看如何提交位点。
2.2 位点提交机制
2.2.1 客户端拉取到合适的消息位点提交机制
Pull线程从服务端拉取到结构后会将消息提交到消费组线程池,主要定义在DefaultMQPushConsumerImpl的PullTask类中,具体代码如下所示:
众所周知,RocketMQ是在消费成功后进行位点提交,代码在ConsumeMessageConcurrentlyService中,如下所示:
这里的核心要点:
文章转自公众号:中间件兴趣圈