RabbitMQ生产者与消费者通过Exchange和Queue解耦，生产者发消息至Exchange由其路由到Queue，消费者监听绑定的Queue；需声明持久化Exchange/Queue、设置手动确认与发布确认保障可靠性。
RabbitMQ 的生产者与消费者模型本质是解耦消息发送方和接收方，通过中间的 Exchange 和 Queue 实现异步通信。核心在于生产者只关心发消息到 Exchange，消费者只监听绑定的 Queue，双方无需知道彼此存在。
生产者：声明 Exchange 并发布消息
生产者不直接向队列发送消息，而是将消息发往 Exchange（交换机），由 Exchange 根据类型（如 direct、topic、fanout）和路由规则分发到一个或多个 Queue。需注意：Exchange 需提前声明（即使不存在也会自动创建，但显式声明更可控），且建议设置 durable=true 保证重启后仍存在。
- 使用 pika 库时，调用 channel.exchange_declare() 声明 Exchange
- 发送消息用 channel.basic_publish()，指定 exchange 名称、routing_key（对 direct/topic 有效）、body（消息体）
- 消息可设置 properties（如 delivery_mode=2 实现持久化），避免服务宕机时丢失
消费者：绑定 Queue 并监听消息
消费者需先确保 Queue 存在，并将其绑定到目标 Exchange（指定 routing_key 或 binding_key），然后调用 basic_consume 启动监听。RabbitMQ 默认采用推模式（push），消息就绪即主动推送，而非轮询拉取。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 声明 Queue 时建议设 durable=True，避免重启后队列消失
- 绑定用 channel.queue_bind()，参数包括 queue、exchange 和 routing_key
- 消费逻辑封装在回调函数中，通过 channel.basic_qos(prefetch_count=1) 控制并发处理数，防止消费者过载
关键机制：确认与重试保障可靠性
默认情况下，RabbitMQ 在消息投递到消费者后即删除，若消费者异常退出会导致消息丢失。启用手动确认（manual ack）可提升可靠性：消费者处理完再显式发送 ack，否则消息会重回队列（或进入死信队列）。
- 消费者端设置 auto_ack=False，并在处理成功后调用 channel.basic_ack(delivery_tag=method.delivery_tag)
- 若处理失败，可用 basic_nack(requeue=True) 让消息重新入队，或 requeue=False 转发至死信 Exchange
- 生产者可开启 publisher confirms，等待 broker 返回确认，确保消息已到达 Exchange
常见结构示例：Direct Exchange 场景
例如订单系统中，不同订单类型（order.created、order.paid）作为 routing_key，消费者按需绑定对应 key。一个 Exchange 可对接多个 Queue，每个 Queue 只接收匹配 routing_key 的消息，实现精准路由。
- 生产者发消息时指定 routing_key="order.created"
- 库存服务绑定 queue="inventory_queue" 到 exchange，binding_key="order.created"
- 支付服务绑定 queue="payment_queue"，binding_key="order.paid"
