DOCSEARCHbyAlgolia
Submit Docs

RabbitMQ Blog

website·Indexed 29 days ago

https://rabbitmq-website.pages.dev/

Official blog for RabbitMQ, featuring release announcements for versions such as 2.1.1, 2.4.0, 2.5.0, 3.3.0, 3.9.0, and 3.10.0, as well as technical deep dives into AMQP, topic routing, publisher confirms, and broker performance benchmarks.

Tokens
1.7M
Snippets
6.8K
Records
12.4K
Agent score
68%

What's inside RabbitMQ

  1. Overview of RabbitMQ configuration mechanisms

    RabbitMQ nodes are configured using several different mechanisms depending on the target settings:

    • Configuration Files: Used for server and plugin settings, TCP listeners, networking, TLS, resource alarms, authentication/authorization backends, and message store settings.
    • Environment Variables: Used for node names, file/directory locations, and runtime flags (configured via shell or rabbitmq-env.conf on Linux/MacOS/BSD and rabbitmq-env-conf.bat on Windows).
    • rabbitmqctl: Manages virtual hosts, users, permissions (when using internal auth), and runtime parameters/policies.
    • rabbitmq-queues: Manages settings specific to quorum queues.
    • rabbitmq-plugins: Manages plugin activation and configuration.
    • rabbitmq-diagnostics: Used to inspect node state, effective configuration, metrics, and health checks.
    • Parameters and Policies: Defines cluster-wide settings that can change at runtime or group-specific settings for queues and exchanges.
    • Runtime (Erlang VM) Flags: Controls low-level system aspects like memory allocation, inter-node communication buffers, and scheduler settings.
    • Operating System Kernel Limits: Controls process limits such as max open file handles, max processes, and kernel threads.

  2. Overview of RabbitMQ Dynamic Shovels

    Dynamic shovels are the modern alternative to static shovels in RabbitMQ. They are configured using runtime parameters and can be started, stopped, or modified programmatically at any time. Because their configuration is stored in RabbitMQ's schema database, they can be exported with other schema definitions and can be combined with 'definition import on boot' to ensure they start after cluster formation.

  3. Overview of RabbitMQ Streams

    RabbitMQ Streams are persistent, replicated, append-only logs of messages. Unlike classic queues, they feature "non-destructive consumer semantics," meaning messages are not deleted after being consumed. This allows multiple consumers to read the same messages repeatedly until the messages expire. While they can be used via AMQP 0.9.1, using the dedicated binary protocol plugin is highly recommended for maximum throughput and access to all stream-specific features.

  4. Overview of RabbitMQ Dynamic Shovels

    Dynamic shovels are the modern alternative to static shovels in RabbitMQ. They are configured using runtime parameters and can be started, stopped, or managed programmatically at any time. Unlike static shovels, dynamic shovel configurations are stored in RabbitMQ's schema database alongside users and queues, allowing them to be exported as part of schema definitions. To ensure dynamic shovels start after cluster formation, they should be used in combination with definition import on boot.

  5. Overview of RabbitMQ Streams

    RabbitMQ Streams are persistent, replicated, append-only logs of messages. Unlike regular queues, streams use "non-destructive consumer semantics," meaning messages are not deleted after being consumed. This allows multiple consumers to read the same messages repeatedly and enables "time-travelling" (replaying messages from a specific point in the log).

    Streams are recommended for the following use cases:

    1. Large fan-outs: Multiple consumers can read the same stream without needing separate queues for each.
    2. Replay: Consumers can attach to any point in the log to re-read data.
    3. High Throughput: Designed specifically for performance to compete with log-based messaging systems.
    4. Large Backlogs: Optimized for storing millions of messages with minimal in-memory overhead.

  6. Overview of Direct Reply-To for RPC

    Direct Reply-To is a RabbitMQ-specific feature that enables the RPC (request/reply) pattern without requiring the creation of a dedicated reply queue. It eliminates the need to write queue metadata to the metadata store (Khepri), removes the need for queue buffers, and reduces the number of Erlang processes on the broker. The responder's session or channel delivers the reply directly to the requester's session or channel via the broker.

  7. Overview of RabbitMQ Quorum Queues

    Quorum queues are a modern, durable, and replicated queue type based on the Raft consensus algorithm. They are designed for high availability and data safety, making them the default choice for replicated queues in RabbitMQ 4.0+. They ensure that a majority of nodes (a quorum) agree on the state of the queue, providing reliability during network partitions, failures, or upgrades. Note that classic queue mirroring was removed in RabbitMQ 4.0.

  8. Overview of Dynamic Shovels in RabbitMQ

    Dynamic shovels in RabbitMQ 3.13 are configured using runtime parameters and can be started, stopped, or managed programmatically. Unlike static shovels, dynamic shovel configurations are stored in RabbitMQ's schema database, allowing them to be exported alongside other schema definitions (like users and queues). They can be used for both transient one-off tasks and permanent workloads.

  9. Overview of Dynamic Shovels in RabbitMQ

    Dynamic shovels are the modern alternative to static shovels in RabbitMQ. They are configured using runtime parameters and can be started, stopped, or modified programmatically at any time. Unlike static shovels, dynamic shovel configurations are stored in RabbitMQ's schema database alongside users and permissions, allowing them to be exported as part of schema definitions. For workloads that must start immediately after cluster formation, dynamic shovels should be combined with the 'definition import on boot' feature.

  10. Overview of RabbitMQ Streams

    RabbitMQ Streams are persistent, replicated, append-only logs of messages. Unlike regular queues, which have destructive consumer semantics (messages are deleted after consumption), streams provide non-destructive semantics, allowing messages to be read repeatedly by multiple consumers until they expire. They are specifically designed for high-throughput performance, large fan-outs, message replay (time-travelling), and handling large backlogs with minimal memory overhead.

  11. Overview of Direct Reply-To for RPC

    Direct Reply-To is a RabbitMQ-specific feature that enables the implementation of RPC (request/reply) patterns without requiring the creation of a dedicated reply queue. By eliminating the need for queue metadata in the store (Khepri), queue buffers, and separate Erlang processes for each reply queue, it significantly reduces load on the broker's metadata store and Management HTTP API.

    Key benefits include:

    • Reduced metadata store load (no insert/delete of queue metadata).
    • Fewer queues and metrics in the Management UI.
    • Lower resource consumption on the broker.

    Replies are delivered directly from the responder's session/channel to the requester's session/channel via the broker.

  12. Overview of TLS support in RabbitMQ 4.0

    RabbitMQ 4.0 provides built-in support for TLS to secure client connections, popular plugins (such as Federation links), and inter-node connections within clusters. TLS can be enabled for all supported protocols, including AMQP 1.0, AMQP 0-9-1, Stream, MQTT, and STOMP, as well as the HTTP Management API and CLI tool traffic.