RocketMQ整个流程

1.发送消息,producer会在本地缓存的broker列表里面获取一个broker,如果没有,那就会去namesrv获取broker的地址,然后发
送消息到broker。
2.broker接受到消息后,会进行一系列检查,然后把收到的消息,存入到commitLog当中,然后进行刷盘,如果是同步的刷盘策略
,那么就会在写入到pageCache中时,再真正落地到磁盘的时候才会进行response的返回,如果是异步的话,那么会在写入
pageCache中时即可返回response,然后累计一定量的消息的时候才会持久化,相应的,异步的策略的效率更高了,可是带来的就
是风险性的评估,那么这个时候选择就需要根据实际情况来考虑问题了。
3.后台有一个线程ReputMessageService一直在查看commitLog的偏移量,如果commitLog的写入偏移了,那么这个时候就会把消息
的长度,id,起始位置等传送给consumeQueue,和index(index就是索引,根据topic和id得到相应msg的位置)。
4.consumer端消费,有两种模式,push和pull模式,其实都是基于pull来做的,PullMessageProcessor里面是相应的逻辑处理,大
致的处理流程:系统能够知道每个consumeQueue现在读取到的位置,如果没有消息未读取的话,就会阻塞response,默认20s。当
有消息的时候,先会去读取consumeQueue,然后读取出消息的起始位置等,然后去commitLog读取消息,并且修改commitLog中的消
息的读取次数等,消费者接着处理业务逻辑,然后返回给broker相应的结果,如果消费成功,那么修改consumeQueue的消费的位置
(不一定刷盘,所以需要保证业务端幂等)。如果消费失败,那么普通消息就会进入到重试队列,(类似于延时队列)进行重试,
达到一定重试次数之后仍然失败,那么就会放入到死信队列当中,这个时候需要人工介入(例如这个时候,可以在这个地方进行源
码的二次开发,或者注册监听器,当有消息放入死信队列的时候就发送提醒)。
 

你可能感兴趣的:(RocketMq,RocketMq)