The RabbitMQ transport has the concept of a routing topology, which controls how it creates exchanges, queues, and the bindings between them in the RabbitMQ broker. The routing topology also controls how the transport uses the rabbitmq-config-useroutingtopologyexchanges it creates to send and publish messages.
By default, the RabbitMQ transport uses the
ConventionalRoutingTopology, which relies on fanout exchanges to route messages.
Each endpoint creates its own fanout exchange and queue, using its own name as the name of the exchange and queue. It also creates a binding between the exchange and queue. Messages are sent to the endpoint by sending them to the endpoint's exchange. The binding then routes the message to the endpoint's queue.
For each type being published, a series of fanout exchanges are created to model the inheritance hierarchy of the type. For each type involved, an exchange is created, named in the following format:
Namespace:TypeName. Bindings are created between the types, going from child to parent, until the entire hierarchy has been modeled. Exchanges are also created for each interface the type implements.
When an endpoint subscribes to an event, it first ensures that the above infrastructure exists. It then adds a binding from the exchange corresponding to the subscribed type to its own exchange.
When an endpoint publishes an event, it first ensures that the above infrastructure exists. It then sends the message to the exchange corresponding to the type being published.
DirectRoutingTopology routes all events through a single exchange,
amq.topic by default. Events are published using a routing key based on the event type, and subscribers will use that key to filter their subscriptions.
Every endpoint creates a queue with a name that is equal to the endpoint name. When an endpoint sends a message it sends it to a default exchange with a routing key equal to the destination endpoint name. This makes use of RabbitMQ default exchanges to move the message to a queue with the same name.
Every endpoint publishes an event using the
amq.topic exchange with a routing key of the form 'Namespace.TypeName', corresponding to the type of the event. The event is moved to all queues that have a binding for that event type.
An endpoint that subscribes to a given event creates a binding to the default exchange with the appropriate routing key.
To enable the direct routing topology, use the following configuration:
var transport = busConfiguration.UseTransport<RabbitMQTransport>(); transport.UseDirectRoutingTopology();
Adjust the conventions for exchange name and routing key by using the overload:
var transport = busConfiguration.UseTransport<RabbitMQTransport>(); transport.UseDirectRoutingTopology( routingKeyConvention: MyRoutingKeyConvention, exchangeNameConvention: (address,eventType) => "MyTopic");
If the built-in routing topologies do not satisfy the requirements of the system, a custom routing topology may be used. To do this:
- Define the routing topology by creating a class implementing
- Register it with the transport calling
UseRoutingTopologyas shown below.
The generic overload of
UseRoutingTopology is still supported in Versions 4.x but it is marked as
[Obsolete] with a warning. The warning will become an error in Version 5.0 and the overload will be removed in Version 6.0.
var transport = busConfiguration.UseTransport<RabbitMQTransport>(); transport.UseRoutingTopology<MyRoutingTopology>();
For each queue required by the endpoint, the transport will first declare that queue and will then call the
Initialize method of the routing topology. The routing topology should then perform all initialization related to that specific queue such as the creation of appropriate exchanges and bindings.