About this chapter
You can now produce, consume, route and acknowledge messages, and even run them through
Laravel. This chapter is about keeping RabbitMQ alive once real traffic depends on it. You'll
learn to read the broker's health from the management UI and the rabbitmqctl command line,
lock it down with real users and permissions instead of guest, choose durable quorum queues,
understand what a cluster does (and does not) buy you, react when a memory or disk alarm blocks
your publishers, and secure the whole thing so it never ends up open to the internet.
Lessons from courses
- 1 Monitoring with the management UI Monitor RabbitMQ queues in the management UI: Ready vs Unacked, publish and deliver rates, consumer count and memory, and what a rising backlog means.
- 2 rabbitmqctl basics Common rabbitmqctl commands run inside Docker: list_queues, list_exchanges, list_connections and status, plus when the CLI beats the management UI.
- 3 Users, vhosts and permissions Set up RabbitMQ users and permissions for production: create users with add_user and set_user_tags, isolate apps with vhosts, and grant least-privilege access.
- 4 Quorum queues RabbitMQ quorum queues are the modern replicated, durable queue type. Declare one with x-queue-type, see why they replaced mirrored queues, and weigh the trade-offs.
- 5 Clustering and high availability How RabbitMQ clustering delivers high availability: node availability, quorum queues for replication, and why a cluster alone is not a throughput button.
- 6 Memory and disk alarms How the RabbitMQ memory alarm and free-disk alarm work: the high-watermark thresholds, why the broker blocks publishers with flow control, and how to clear it.
- 7 Securing RabbitMQ Secure RabbitMQ in production: enable TLS on 5671, use strong credentials, delete the guest user, firewall ports 5672 and 15672, and grant least-privilege users.