| 模式/特性      | 交换机类型             | 关键词                    | 典型场景  |
| ---------- | ----------------- | ---------------------- | ----- |
| Simple     | 默认直连              | 单队列                    | 点对点   |
| Work Queue | 默认直连              | prefetch               | 并行任务  |
| Pub/Sub    | fanout            | 广播                     | 群发通知  |
| Routing    | direct            | routing\_key 精确        | 日志分级  |
| Topic      | topic             | 通配符                    | 多维度路由 |
| Header     | headers           | 键值对匹配                  | 元数据路由 |
| RPC        | 默认直连              | reply\_to+corr\_id     | 远程调用  |
| Delay      | x-delayed-message | x-delay                | 定时任务  |
| Priority   | 任意                | priority               | 插队处理  |
| DLX        | 任意                | x-dead-letter-exchange | 失败转移  |
| Lazy       | 任意                | x-queue-mode=lazy      | 海量堆积  |
| Quorum     | 任意                | x-queue-type=quorum    | 高可用   |
| Stream     | stream            | offset                 | 日志流   |


──────────────────
1️⃣ Routing（路由）模式
交换机类型：direct（直连）
只把消息送到 routing_key 精确匹配 的队列。
场景：按业务类型分 queue，比如日志分级（info、warn、error）。
最小 demo 指路：
producer：channel.basic_publish(exchange='direct_logs', routing_key='error', body=…)
consumer：channel.queue_bind(queue=xxx, exchange='direct_logs', routing_key='error')
──────────────────
2️⃣ Topic（主题）模式
交换机类型：topic
routing_key 用 “点分单词” 通配符匹配（* 单层，# 多层）。
场景：日志按模块+级别（order.info、order.error、payment.*）或 IM 离线消息多租户。
最小 demo 指路：
producer：routing_key = "order.created.us"
consumer：bind routing_key = "order.*.us" or "order.#"
──────────────────
3️⃣ Header（头部）模式
交换机类型：headers
路由规则由消息头里的键值对决定，完全忽略 routing_key。
场景：需要根据多个元数据字段（如 x-version:1,x-env:prod）灵活路由，且不想把信息放进 routing_key。
最小 demo 指路：
producer：properties=pika.BasicProperties(headers={'x-version':'1','x-env':'prod'})
consumer：channel.queue_bind(queue=xxx, exchange='header_logs', arguments={'x-match':'all','x-version':'1','x-env':'prod'})
──────────────────
4️⃣ Work Queue（竞争消费 / 任务队列）
本质：简单队列 + 多消费者 + basic_qos=1
把耗时任务均匀分发给多个 worker，一条消息只被一个消费者拿到。
场景：图片压缩、批量邮件、爬虫任务。
你已经学过，就是简单模式里加 prefetch_count 那段。
──────────────────
5️⃣ RPC 模式
交换机类型：默认直连（""）
客户端像调本地函数一样，把“函数名 + 参数”塞进队列；服务端算完后把结果塞回客户端的私有回调队列，用 correlation_id 保证“一问一答”不串线。
关键要素
队列：客户端创建独占临时队列当“回执邮箱”；服务端监听固定队列 rpc_queue。
消息属性：reply_to（回执邮箱地址）、correlation_id（请求 ID）。
阻塞/轮询：客户端用 process_data_events() 或 start_consuming() 等结果。
典型场景
微服务之间“同步”调用（下单服务 → 库存服务扣库存并返回剩余数量）。
异构语言互通（Python 调 Java 的算法库）。
──────────────────
6️⃣ 发布订阅 / Fanout 模式
交换机类型：fanout
消息来了就广播给所有绑定到这个交换机的队列，每条消息可被所有消费者各自收到一次。
关键要素
队列：通常由消费者在绑定时自动生成（exclusive=True 或 queue=""），生命周期跟随连接。
绑定：任何队列只要 queue_bind(exchange='logs') 就能收到广播。
消息丢失：交换机没有队列绑定时，消息直接丢弃。
典型场景
群发通知 / 公告（所有在线用户收到同一推送）。
日志汇聚：一个交换器 logs 同时发给“文件落盘队列”“监控大屏队列”“实时告警队列”。
──────────────────
7️⃣ 延迟队列（Delayed Message）
RabbitMQ 官方插件：rabbitmq_delayed_message_exchange
让消息 延迟 N 秒 后才投递。
场景：订单 15 分钟未支付自动关单、定时提醒。
使用：声明交换机 type = 'x-delayed-message'，发消息时 header 加 x-delay=15000。
──────────────────
8️⃣ 优先级队列（Priority Queue）
官方插件已内置。
队列里高 priority 的消息先被消费。
场景：VIP 用户任务插队。
使用：queue_declare(arguments={'x-max-priority':10})，publish 时加 priority=5。
──────────────────
9️⃣ 死信队列（DLX / DLQ）
消息“死”了（被拒绝、TTL 到期、队列满）就自动转到另一个交换机 → 死信队列。
场景：失败任务人工审计、防丢消息。
使用：queue_declare(arguments={'x-dead-letter-exchange':'dlx'})，再建 dlx 绑定的队列。
──────────────────
🔟 惰性队列（Lazy Queue）
消息优先落磁盘，百万级堆积 场景下内存更稳。
使用：queue_declare(arguments={'x-queue-mode':'lazy'})
──────────────────
1️⃣1️⃣ 仲裁队列（Quorum Queue）
RabbitMQ 3.8+ 新特性，替代经典镜像队列。
Raft 协议复制，高可用 + 强一致，牺牲少量吞吐。
使用：queue_declare(queue='q1', durable=True, arguments={'x-queue-type':'quorum'})
──────────────────
1️⃣2️⃣ Stream（流式日志）
RabbitMQ 3.11+ 实验特性。
Kafka-like 的 append-only log，支持大量客户端、回溯消费。
使用：stream 声明 + offset tracking。