请问一下RocketMQ为什么我业务上写入,怎么只往一组broker写入,另外两组都没有写入,这是怎么回事?
刚刚了解了一下,我们的业务场景是顺序消息,这种场景下是只会往一组broker里面写数据吗?
在RocketMQ中,消息写入的具体Broker是由创建主题(Topic)时指定的。换句话说,你在业务上写入时,消息会被发送到与你的主题关联的Broker上。这个关联是在创建主题的时候确定的,每个主题都会有一个或多个与之关联的队列(Queue),这些队列全部都属于创建主题时指定的那个Broker。
RocketMQ的设计天生就对集群的支持非常友好,它天然支持高可用,可以支持多主多从的部署架构。其中Master的broker id = 0,Slave 的broker id > 0。每个Broker都是RocketMQ集群中的核心部分,负责接收生产者发过来的消息、处理消费者的消息请求、进行消息的持久化存储等重要工作。
RocketMQ使用了一种基于日志的存储方式来存储消息。它将消息以顺序写入的方式追加到文件中的CommitLog。单个文件大小默认是1G,文件名长度为20位(左边补零,剩余为起始偏移量),当文件满了,会写入下一个文件。
CommitLog文件存储了Producer端写入的消息主体内容,它以追加写入的方式将消息存储到磁盘上的文件中。这种存储方式的主要特点是顺序写,但是随机读(被ConsumeQueue读取)。虽然是随机读,但是利用package机制,可以批量地从磁盘读取,作为cache存到内存中,加速后续的读取速度。
Broker单个实例下所有的队列共用一个日志数据文件CommitLog来存储。而Kafka采用的是独立型的存储结构,每个队列一个文件。
ConsumeQueue文件是用于支持消息消费的存储结构。保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset,消息大小size和消息Tag的HashCode值。消费者通过顺序读取ConsumeQueue文件,可以快速定位到消息在CommitLog中的物理存储位置,从而实现快速消息的拉取和消费。
如果一组主从broker都挂了,RocketMQ会采用备份机制来确保数据的可靠性。它会在多个Broker之间进行数据备份,确保数据不会因为某个Broker的故障而丢失。
因此,即使一组主从broker都挂了,RocketMQ仍然能够保证数据的可靠性和完整性。
当你在使用RocketMQ时,如果发现只往一组broker写入消息,而另外两组broker没有写入,可能有以下原因:
发送的时候没有指定队列吧。看业务是不是key没有打散,都往一个broker队列一面发 ,此回答整理自钉群“群2-Apache RocketMQ 中国开发者钉钉群”
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
涵盖 RocketMQ、Kafka、RabbitMQ、MQTT、轻量消息队列(原MNS) 的消息队列产品体系,全系产品 Serverless 化。RocketMQ 一站式学习:https://rocketmq.io/