Skip to content

Instantly share code, notes, and snippets.

@kjnilsson

kjnilsson/10tips.md

Last active December 20, 2021 09:15
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kjnilsson/fbcee389183f8b5965927f062b265e73 to your computer and use it in GitHub Desktop.
Save kjnilsson/fbcee389183f8b5965927f062b265e73 to your computer and use it in GitHub Desktop.
Download ZIP
10 (8) RabbitMQ tips you may not be aware of
Raw
10tips.md

10 RabbitMQ tips you didn't know

  1. Don't retry publishes to Quorum Queues or Streams if the channel is still live.

    Normally we recommend to retry a publish operation if a publisher confirm isn't received within some timeframe. This isn't actually necessary if you know you are only publishing to quorum queues and/or streams and the channel used for publishing is still live. These queue types have their own reliability/resend protocol between the channel and the queue and will ensure publish operations get there once the situation that caused the delay resolves itself (e.g. a temporary unavailability due to network conditions etc). If the channel or connection is terminated before confirms are received you should still retry of course.

  2. Use multiple queues for priorities instead of a priority queue.

    You get both scaling and better per-priority metrics and visibility. Also you can configure message ttl on low priority queues to be promoted to a higher priority queue if they aren't processed within some timeframe allowing much better scheduling and SLA facilities than priority queues.

  3. Single Active consumer queues provide ordering guarantees and high consumer availability for consumers even when using high prefetch values.

  4. Use the consistent hashing exchange with single active consumer quorum queues to scale out processing but retain ordering per hashing queue (e.g. customer id).

  5. Configure Quorum Queues with max-in-memory-length=0 to reduce the amount of memory used by these queues. Also set delivery-limit and max-length to ensure a single queue won't affect the entire cluster negatively. Set a policy to apply this configuration to all Quorum Queues. You will not regret it.

  6. Use "windowed confirms"

  7. Don't ever use global QoS on a channel. It is slower and provide little value.

  8. Use a stream for auditing. Streams are good for accepting and holding on to lots of messages with very little overhead and their immutable nature makes them suitable for such use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment