上图是大概的流程.发送消息
producer发送消息时从namesever获取该消息topic的所有messageQueue,从这些messageQueue中随机抽取一个发送.
当然也可以指定一个发送,这样可以保证消息的有序性,因为只有一个messageQueue保存了该topic下的所有消息,而且消费者消费的队列是固定的,但是如果消费者能力有限,那么会导致消息堆积,无法及时被消费.
broker接收到消息后会给producer一个确认,producer没接到确认的话会一直重复发送.
就算这个消费者宕机了,来接手这个messageQueue的新消费者也是从这个messageQueue一个一个取出来的,不用担心顺序会乱.
如果brokerA宕机了,就会出现顺序打乱的问题:
如果是主brokerA宕机,那么producerA发送消息时指定的messageQueue不存在了也就是无法连接了,那么producerA就会向另一个正常的brokerB的messageQueue发送消息,
此时宕机的主brokerA的从brokerA内还有未消费完的消息,还正常提供服务,而brokerB也开始为该topic提供服务,多个broker提供服务,顺序就会乱掉.
如果是从brokerA宕机,那么producerA正常向主brokerA发送消息,消费者从主brokerA也可以接受到消息.保存消息
消息到了broker后,broker会将消息写入内存,并将消息同步给从broker,同步完成后返回一个ack(确认消息)给producer.
这里涉及到消息的刷盘机制以及主从同步机制,这里是主从同步更新后异步刷盘.获取消息
消费者订阅topic,namesever给消费者绑定topic的messageQueue,每个消费者绑定一个或者多个messageQueue,而一个messageQueue只会绑定一个消费者.
消费者从messageQueue用pull的方式获取消息,将消息消费后返回ack(确认)给broker,那么这条消息就消费完成了.
如果ack由于网络原因传输失败,则会导致broker将消息重复传递,所以要确保消息的幂等性.
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
