Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggest to use quorum queues instead of classic #112

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion rabbitmqent.html.md.erb
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,14 @@ By default, every queue created on RabbitMQ is created on one node (the queue ma

In certain cases, high availability is sacrificed to avoid the overhead of replication to achieve higher performance. For this, just create the queue with the prefix `appcloud-non-ha` and it will not be replicated to other nodes.

#### Quorum Queues

Quorum queues were introduced in RabbitMQ 3.8 version. This type of queue implements a replicated FIFO queue based on Raft consensus algorithm. It came to "replace" classic mirrored queues as a more reliable solution for high availability with still good throughput.

To use quorum queues, just create the queue with the quorum type.

Classic Queues are deprecated and will be removed in RabbitMQ 4.0. Furthermore in times of high load classic queues can get corruped and lose synchronisation, this is a know limitation of RabbitMQ.

#### Consistent Hash exchange
For a different approach to scale your queues on the cluster, the [Consistent hash exchange plugin](https://github.com/rabbitmq/rabbitmq-consistent-hash-exchange) is enabled.

Expand Down Expand Up @@ -226,4 +234,4 @@ Large messages can take up a lot of resources and should generally be avoided. R
#### Message ack's and confirms
RabbitMQ features acknowledgments (ack's) for receiving message and publisher confirms (confirms) for sending messages. These mechanisms can be used to ensure that a message has been send / received correctly. Ack's and confirms are generally a good idea to implement as they increase the reliability and consistency of the message flow.

Note: Ack's and confirms have a small performance impact.
Note: Ack's and confirms have a small performance impact.