Обмены, очереди и привязки: объяснение

Producers don't publish to queues directly. Three pieces route a message: an exchange receives it, a binding links it, and a queue stores it.

An exchange is the entry point. A producer publishes to it, and the exchange decides which queues should get the message based on its rules.

A binding is the rule connecting an exchange to a queue, usually with a routing key or pattern that decides whether a message matches.

A direct exchange routes to queues whose binding key exactly matches the message's routing key — ideal for point-to-point routing.

A fanout exchange ignores routing keys and broadcasts every message to all bound queues. Perfect for pub/sub where everyone needs everything.

A topic exchange routes by wildcard pattern: * matches one word, # matches many. So order.* catches order.created and order.shipped.

A headers exchange routes on message header attributes instead of a routing key — the most flexible type, and the least used.

The nameless default exchange binds every queue by its own name. Publish with a routing key equal to a queue name and it lands there directly.

Declare a queue before using it, and mark it durable so it survives a broker restart. The code does exactly that.

The full flow: a producer publishes to an exchange with a routing key, bindings match, the right queues store it, and consumers read.

Picking an exchange type: exact key → direct, broadcast → fanout, pattern → topic, header rules → headers.

You picked an exchange type. Now match the routing behavior to the job.

That's RabbitMQ routing: exchanges route, queues store, bindings connect — and direct, fanout, and topic each shape how messages flow.