RabbitMQ cluster mode for classic queues is not a true HA solution. If a node gets replaced the content of your queue has to be synchronized to the new node and while this is running you can't produce to the queue which is an outage. Unfortunately this synchronization method is also unreliable if you have a significant (a few GB) amount of messages in the queue, it often crashes nodes with no way to recover the internal database. And even if everything works you still have a chance of lost messages or lost acks (to be fair, this is documented). It is so bad that it is now officially deprecated.
This also makes online upgrades extremely hard, the only acceptable way is to stand up a new cluster, switch producers and consumers and then shovel the data from the old cluster (which is also not too reliable).
They came up with quorum queues which have less features and require to keep all messages in memory. I don't like having servers with 90% unused memory for that one event where I actually need to queue a lot of messages because a consumer is broken.
I would never pump logs through RabbitMQ, if you get into a situation where you accumulate a large amount of data in a queue you will face trouble sooner or later. Most likely RabbitMQ will run out of memory, will "flow-control" producers and you'll have an outage you can't recover from.
> They came up with quorum queues which have less features and require to keep all messages in memory.
I don't think this is true
> Quorum queues store their message content on disk (per Raft requirements) and only keep a small metadata record of each message in memory. This is a change from prior versions of quorum queues where there was an option to keep the message bodies in memory as well. This never proved to be beneficial especially when the queue length was large.
You are correct, nice to see that this was improved.
I should find time to run some tests with quorum queues, this now actually looks usable. But in the end we will have to see how stable it is running production workloads.
This also makes online upgrades extremely hard, the only acceptable way is to stand up a new cluster, switch producers and consumers and then shovel the data from the old cluster (which is also not too reliable).
They came up with quorum queues which have less features and require to keep all messages in memory. I don't like having servers with 90% unused memory for that one event where I actually need to queue a lot of messages because a consumer is broken.
I would never pump logs through RabbitMQ, if you get into a situation where you accumulate a large amount of data in a queue you will face trouble sooner or later. Most likely RabbitMQ will run out of memory, will "flow-control" producers and you'll have an outage you can't recover from.