请问一下RocketMQ为什么我业务上写入,怎么只往一组broker写入,这是怎么回事?-[阿里云_云淘科技]

请问一下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没有写入，可能有以下原因：

• Broker配置问题：首先检查你的RocketMQ配置，确保所有broker都正确配置并启动。确保所有broker的地址和端口都正确，并且它们都在同一个集群中。
• 路由规则问题：RocketMQ使用路由规则来确定消息应该发送到哪个broker。检查你的路由规则配置，确保它们正确地将消息路由到所有可用的broker。
• 负载均衡问题：RocketMQ使用负载均衡算法将消息分配给可用的broker。检查你的负载均衡配置，确保它能够将消息均匀地分配给所有可用的broker。
• 网络问题：检查网络连接，确保所有broker之间的网络连接是正常的。如果网络存在问题，可能会导致某些broker无法接收到消息。
• 消息生产者问题：检查你的消息生产者代码，确保它正确地将消息发送到RocketMQ。确保生产者使用的地址和端口与RocketMQ的配置一致。
• 日志和监控信息：查看RocketMQ的日志和监控信息，了解是否存在任何错误或异常。这可以帮助你诊断问题的原因。

以下为热心网友提供的参考意见

发送的时候没有指定队列吧。看业务是不是key没有打散，都往一个broker队列一面发 ，此回答整理自钉群“群2-Apache RocketMQ 中国开发者钉钉群”