concept topic exchange in category rabbitmq
This is an excerpt from Manning's book RabbitMQ in Depth.
When declaring the alternate exchange, a fanout exchange type was selected, whereas the graphite exchange uses a topic exchange. A fanout exchange delivers messages to all the queues it knows about; a topic exchange can selectively route messages based upon parts of a routing key. These two exchange types are discussed in detail in chapter 5. Once the two exchanges are declared, the unroutable-messages queue is bound to the alternate exchange. Any messages that are subsequently published to the graphite exchange and that can’t be routed will end up in the unroutable-messages queue.
In the preceding example routing keys, the semantic importance of the routing key should clearly stand out, describing the intent or content of the message. By using semantically named keys for messages routed through the topic exchange, a single message can be routed by subsections of the routing key, delivering the message to task-specific queues. In figure 6.11, the topic exchange determines which consumer application queues will receive a message based on how they were bound to the exchange.
Figure 6.11. Messages are selectively routed to different queues based on the composition of their routing keys.
A topic exchange is excellent for routing a message to queues so that single-purpose consumers can perform different actions with it. In figure 6.11, the queue for the facial-detection RPC worker is bound to image.new.profile, behaving as if it were bound to a direct exchange, receiving only new profile image requests. The queue for the image-hashing consumer is bound to image.new.#, and will receive new images regardless of origin. A consumer that maintains a materialized user directory could consume from a queue bound to #.profile and receive all messages ending in .profile to perform its materialization tasks. Image-deletion messages would be published to a queue bound to image.delete.*, allowing a single consumer to remove all images uploaded to the site. Finally, an auditing consumer bound to image.# would receive every image-related message so it could log information to help with troubleshooting or behavioral analysis.
Single-purpose consumers leveraging architecture like this can be both easier to maintain and to scale, compared to a monolithic application performing the same actions on messages delivered to a single queue. A monolithic application increases operational and code complexity. Consider how a modular approach to writing consumer code simplifies what would otherwise be complex actions, such as moving hardware, increasing processing throughput by adding new consumers, or even just adding or removing application functionality. With a single-purpose, modular approach using a topic exchange, appropriate new functionality can be composed of a new consumer and queue without impacting the workflow and processing of other consumer applications.