Binding keys and routing keys in RabbitMQ - Commands & Configuration

Introduction

When sending messages in RabbitMQ, you need a way to decide which messages go to which queues. Binding keys and routing keys help match messages to queues so the right consumers get the right messages.

When you want to send messages to specific queues based on message content

When you need to filter messages so only certain queues receive them

When you want to use a topic exchange to route messages by patterns

When you want to connect multiple queues to one exchange with different filters

When you want to organize message flow in a publish-subscribe system

Config File - rabbitmq_binding_example.sh

rabbitmq_binding_example.sh

#!/bin/bash

# Declare a topic exchange named 'my_topic_exchange'
rabbitmqadmin declare exchange name=my_topic_exchange type=topic

# Declare two queues
rabbitmqadmin declare queue name=queue_errors durable=true
rabbitmqadmin declare queue name=queue_logs durable=true

# Bind queue_errors to the exchange with binding key 'error.*'
rabbitmqadmin declare binding source=my_topic_exchange destination=queue_errors routing_key=error.*

# Bind queue_logs to the exchange with binding key '*.log'
rabbitmqadmin declare binding source=my_topic_exchange destination=queue_logs routing_key=*.log

This script creates a topic exchange called my_topic_exchange. It then creates two queues: queue_errors and queue_logs. Each queue is bound to the exchange with a binding key pattern. queue_errors receives messages with routing keys starting with error., and queue_logs receives messages with routing keys ending with .log. This setup routes messages based on their routing keys matching the binding keys.

Commands

Create a topic exchange named 'my_topic_exchange' where messages will be sent and routed based on routing keys.

Terminal

rabbitmqadmin declare exchange name=my_topic_exchange type=topic

Expected Output

Successfully declared exchange 'my_topic_exchange'

→

type=topic - Defines the exchange type to route messages by pattern matching routing keys

Create a durable queue named 'queue_errors' to receive error messages.

Terminal

rabbitmqadmin declare queue name=queue_errors durable=true

Expected Output

Successfully declared queue 'queue_errors'

→

durable=true - Ensures the queue survives RabbitMQ restarts

Create a durable queue named 'queue_logs' to receive log messages.

Terminal

rabbitmqadmin declare queue name=queue_logs durable=true

Expected Output

Successfully declared queue 'queue_logs'

→

durable=true - Ensures the queue survives RabbitMQ restarts

Bind 'queue_errors' to the exchange with binding key 'error.*' so it receives messages with routing keys starting with 'error.'.

Terminal

rabbitmqadmin declare binding source=my_topic_exchange destination=queue_errors routing_key=error.*

Expected Output

Successfully declared binding from 'my_topic_exchange' to 'queue_errors' with routing key 'error.*'

→

routing_key=error.* - Filters messages to those with routing keys matching 'error.*'

Bind 'queue_logs' to the exchange with binding key '*.log' so it receives messages with routing keys ending with '.log'.

Terminal

rabbitmqadmin declare binding source=my_topic_exchange destination=queue_logs routing_key=*.log

Expected Output

Successfully declared binding from 'my_topic_exchange' to 'queue_logs' with routing key '*.log'

→

routing_key=*.log - Filters messages to those with routing keys matching '*.log'

Key Concept

Binding keys on queues and routing keys on messages work together to route messages to the right queues based on matching patterns.

Common Mistakes

Using the same string for binding key and routing key without understanding pattern matching

Messages may not be routed as expected because topic exchanges use patterns like '*' and '#' for matching

Use wildcards '*' and '#' in binding keys to match routing keys patterns properly

Binding queues to the wrong exchange type (e.g., direct instead of topic)

Routing keys are interpreted differently depending on exchange type, causing routing failures

Ensure the exchange type matches the routing logic you want, like 'topic' for pattern matching

Not declaring queues before binding them to exchanges

Bindings fail because the queue does not exist yet

Always declare queues before creating bindings

Summary

Create a topic exchange to route messages based on routing keys.

Declare queues that will receive messages filtered by binding keys.

Bind queues to the exchange with binding keys that use patterns to match routing keys.

Messages sent with routing keys matching binding keys are delivered to the correct queues.

Practice

1. What is the main purpose of a binding key in RabbitMQ?

easy

A. To label messages for routing

B. To create a new exchange

C. To connect a queue to an exchange and filter messages

D. To delete a queue

Solution

1. Step 1: Understand the role of binding keys

   Binding keys link queues to exchanges and decide which messages the queue receives.

2. Step 2: Differentiate from routing keys

   Routing keys label messages, but binding keys filter messages for queues.

3. Final Answer:

   To connect a queue to an exchange and filter messages -> Option C

4. Quick Check:

   Binding key = filter for queues [OK]

Hint: Binding keys link queues to exchanges filtering messages [OK]

Common Mistakes:

• Confusing binding keys with routing keys
• Thinking binding keys create exchanges
• Assuming binding keys delete queues

2. Which of the following is the correct syntax to bind a queue named myQueue to an exchange myExchange with a binding key key.* using RabbitMQ CLI?

easy

A. rabbitmqadmin declare binding source=myExchange destination=myQueue routing_key=key.*

B. rabbitmqctl bind_queue myExchange myQueue key.*

C. rabbitmqctl declare binding myQueue myExchange key.*

D. rabbitmqadmin bind myQueue myExchange key.*

Solution

1. Step 1: Identify the correct RabbitMQ CLI command

   The rabbitmqadmin declare binding command is used to create bindings with source, destination, and routing_key parameters.

2. Step 2: Match parameters to syntax

   Source is the exchange, destination is the queue, and routing_key is the binding key pattern.

3. Final Answer:

   rabbitmqadmin declare binding source=myExchange destination=myQueue routing_key=key.* -> Option A

4. Quick Check:

   Use rabbitmqadmin declare binding with source, destination, routing_key [OK]

Hint: Use rabbitmqadmin declare binding with source, destination, routing_key [OK]

Common Mistakes:

• Using rabbitmqctl bind_queue which is not a valid command
• Swapping queue and exchange names
• Omitting routing_key parameter

3. Given a topic exchange with a queue bound using binding key logs.*.error, which routing key will deliver a message to this queue?

medium

A. logs.system.error

B. logs.error.system

C. logs.system.warning

D. error.logs.system

Solution

1. Step 1: Understand the binding key pattern

   The binding key logs.*.error matches routing keys with three words where the first is 'logs', the second can be any word, and the third is 'error'.

2. Step 2: Match each option to the pattern

   logs.system.error: 'logs.system.error' matches exactly.
   logs.error.system: 'logs.error.system' ends with 'system', not 'error'.
   logs.system.warning: 'logs.system.warning' ends with 'warning', not 'error'.
   error.logs.system: 'error.logs.system' does not start with 'logs'.

3. Final Answer:

   logs.system.error -> Option A

4. Quick Check:

   Binding key pattern matches routing key exactly [OK]

Hint: Match binding key wildcards to routing key words [OK]

Common Mistakes:

• Ignoring position of words in routing key
• Confusing '*' wildcard with '#' wildcard
• Assuming partial matches are enough

4. You have a queue bound to a topic exchange with binding key data.#. You send a message with routing key data but it is not received by the queue. What is the likely cause?

medium

A. Binding key data.# does not match routing key data

B. Routing key data should be data.#

C. Queue is not bound to the exchange

D. Binding key data.# matches routing key data, so the problem is elsewhere

Solution

1. Step 1: Check if binding key matches routing key

   The binding key data.# matches routing keys starting with 'data' and zero or more words after. The routing key 'data' matches because '#' can match zero words.

2. Step 2: Consider other causes

   Since the binding key matches, the message not arriving is likely due to other issues like queue not bound or exchange type mismatch.

3. Final Answer:

   Binding key data.# matches routing key data, so the problem is elsewhere -> Option D

4. Quick Check:

   Binding key '#' matches zero or more words [OK]

Hint: Remember '#' matches zero or more words including none [OK]

Common Mistakes:

• Thinking '#' requires at least one word
• Assuming routing key must equal binding key exactly
• Ignoring other configuration issues

5. You want to route messages with routing keys order.created and order.updated to a queue named orderQueue using a topic exchange. Which most specific binding key should you use to receive both types of messages?

hard

A. order.created, order.updated

B. order.*

C. *.created, *.updated

D. order.#

Solution

1. Step 1: Understand routing keys and binding keys

   Routing keys are 'order.created' and 'order.updated'. The binding key must match both.

2. Step 2: Analyze each binding key option

   order.*: 'order.*' matches 'order.created' and 'order.updated' because '*' matches exactly one word.
   order.#: 'order.#' matches these and more, but is broader than needed.
   *.created, *.updated: '*.created, *.updated' do not match because the first word must be 'order'.
   order.created, order.updated: 'order.created, order.updated' is not valid syntax for a single binding key; multiple bindings needed.

3. Final Answer:

   order.* -> Option B

4. Quick Check:

   'order.*' matches 'order.created' and 'order.updated' [OK]

Hint: Use 'order.*' to match one word after 'order' [OK]

Common Mistakes:

• Using '#' when '*' is enough
• Trying to use multiple keys in one binding key string
• Misplacing wildcards in binding keys