Will the queue shared by all the rabbitmq pod?

[janiu-001]

Dear expert,

In my k8s env, we have:

1. MQTT plugin, the default exchange is amq.topic
2. New Exchange test-exchange bind amq.topic
3. New queue test-queue bind test-exchange

We found that the queue are bind to rabbit@my-rabbitmq-0.my-rabbitmq-headless.default.svc.cluster.local. According to my understanding, the message could reach all the 3 pods, but now we only have one queue on a specific pod, will all the pods put the messages to this queue?

Very appreciated for your response!

Thanks,
Jason

[janiu-001]

My purpose is to load balance the message node with multiple rabbbitmq pod

[janiu-001]

I tried with [rabbitmq_sharding], i have three node

The following code could not work, how could i consume all the partition on different node

[Zerpet]

You can publish to an exchange from any node in the cluster. In the same way, you can consume from a queue from any node in the cluster. If your queue leader is in, let's say, node-1, and your consumer is connected to node-2 or node-3, the message will be forwarded internally and delivered to the consumer, in the appropriate node. This, and other topics, are covered in the clustering guide in our docs.

If you want to use queue sharding, you must have one consumer per shard. If a single consumer were to consume from all the shards, it won't be distributing the load at all :-) I'd recommend that you read the readme in the queue shard plugin.

I don't know excatly what you are trying to achieve, but if data safety and availability are important to your use case, I'd recommend using Quorum Queues, instead of classic queues. Quorum queues have 3 replicas by default, they persist every message to disk, and they are tolerant to node failures.

[janiu-001]

my purpose is to improve the consume speed, it is not perfect to have one consumer per shard. is there any other solution?
If we have only one queue, it is limitation even we add the consumer

[mkuratczyk]

Generally speaking, having one queue will be your limitation, so make sure you really need one.
There are some opitons such as:

• quorum queues - they provide data safety but also allow consuming from a replica, which may help
• streams - they generally offer higher throughput

This has little to do with Cluster Operator though. If you want to discuss this further, I'd recommend starting a discussion on the mailing list or rabbitmq-server repo and please provide more data about you use case, current throughput you see and throughput you'd expect.

[janiu-001]

i tried to use shard to improve the throughput, but when i have multiple pods, it could not consume the queue with the queue name

For example, the queue name is testing, i have one shard on each pod, like
testing - pod1
testing - pod2
testing - pod2
How could i consume the shared with the queue name testing?

[Zerpet]

If you have a sharded exchange testing, you can consume from the queue shards using the same testing name. RabbitMQ will assign the consumers to queues with the least number of consumers.

Be aware of the note in the readme:

NOTE: there's a small race condition between RabbitMQ updating the queue's internal stats about consumers and when clients issue basic.consume commands. The problem with this is that if your client issue many basic.consume commands without too much time in between, it might happen that the plugin assigns the consumers to queues in an uneven way.

You should also inspect your application to logs to determine why your application can't consume from RabbitMQ.

[janiu-001]

@Zerpet Thanks very much for your info, finally it works. But the queue type created automatically with sharding is "Classical", could we change the queue type to "Quorum"?

[Zerpet]

You should use classic queues with sharding. Sharding was not designed to work with Quorum queues, or with any replicated queue type. Replicating the shards defeats the purposes of sharding. With sharding, you want to distribute data among all the nodes, with replication, you want to have data in all the nodes 😄