페더레이션을 위한 Shovel 플러그인

Welcome to the Shovel plugin! RabbitMQ is great for local messaging, but what if you need to send messages between brokers located far apart, perhaps in different data centers?

The Shovel plugin is designed to reliably move messages from a queue on one RabbitMQ broker to an exchange or queue on another, even across wide area networks (WANs).

The Shovel plugin acts like a bridge, offering several key benefits:

• Broker Decoupling: Connect different RabbitMQ instances without complex network setups or full clustering.
• WAN Reliability: It automatically handles network interruptions and reconnects, ensuring messages eventually reach their destination.
• Data Replication: Useful for disaster recovery scenarios, replicating messages between primary and secondary brokers.
• Version Compatibility: Bridge brokers running different RabbitMQ versions.

Think of Shovel as a persistent helper:

• It consumes messages from a specific source queue on one broker.
• It then publishes these messages to a destination exchange or queue on another broker.
• This process happens continuously and reliably, even if connections temporarily fail.

It's like having a dedicated worker whose only job is to move messages from point A to point B, no matter the distance.

RabbitMQ offers two main types of shovels:

• Static Shovels: These are configured directly on a RabbitMQ node, often via the command-line interface (CLI) or Management UI. They are fixed and run as long as the broker is active.
• Dynamic Shovels: More flexible, these are configured using runtime parameters or policies. They can be created, updated, or deleted on the fly, making them ideal for more transient or policy-driven message flows.

To set up a static shovel, you define its source and destination. Here’s a conceptual CLI command:

rabbitmqctl shovel add [name] --uri=[source_uri] --source-queue=[q_name] --destination-uri=[dest_uri] --destination-exchange=[ex_name]

You specify connection details (URIs) for both brokers and the exact queue/exchange to use.

Let's break down the key parameters for a static shovel:

• --uri: Connection string for the source broker.
• --source-queue: The name of the queue on the source broker from which messages will be consumed.
• --destination-uri: Connection string for the destination broker.
• --destination-exchange (or --destination-queue): The name of the exchange or queue on the destination broker where messages will be published.

The plugin handles all the underlying AMQP connection management.

Dynamic shovels are powerful for managing many similar message flows. Instead of adding each shovel manually, you can define a policy.

A policy specifies rules (e.g., matching queue names with a pattern) that automatically create shovels. This is great for:

• Automatically bridging new queues that match a naming convention.
• Managing shovel configurations centrally.

It's important to monitor your shovels to ensure messages are flowing correctly.

You can check their status using the RabbitMQ Management UI (under the 'Shovels' tab) or via the CLI:

Test your understanding of RabbitMQ Shovel's capabilities.

You've learned about the powerful RabbitMQ Shovel plugin!

• It reliably moves messages between different RabbitMQ brokers.
• Shovel acts as a consumer on a source and a producer to a destination, handling reconnections automatically.
• We covered both static (fixed configuration) and dynamic (policy-driven) shovels.
• Shovel is crucial for integrating systems across WANs, ensuring message durability, and enabling disaster recovery.

It's an essential tool for building robust, distributed messaging systems!