核心模型
Producer ---> Exchange ---> Queue ---> Consumer
Exchange（交换机）是RabbitMq的灵魂，它决定了消息的路由逻辑，这也是它区别于其他MQ的显著特点。
Direct Exchange：精确匹配
routing_key。像一个精确的指令。Fanout Exchange：广播到所有绑定的队列。像一个公司群发邮件。
Topic Exchange：使用通配符匹配
routing_key。像是一个基于标签的订阅系统。Headers Exchange：通过消息头（Headers）匹配，不常用，但功能强大。
优势深度剖析：
1.协议级的“正规军”
AMQP协议：RabbitMQ实现了标准的AMQP0-9-1协议。这意味着不同语言的客户端行为是一致的，链接参数、确认机制等都有统一标准。这比基于TCP协议自定义协议的MQ在跨语言兼容性上更可靠。
管理界面：这是RabbitMQ 的“杀手级”特性之一。你可以不写一行代码，就清晰第看到（各个队列的消息数量状态、消息流入流出的速率、消费者的连接情况、甚至可以手动发送或者拉取消息进行调试）
2.无与伦比的灵活性
得益于多样的Exchange类型，你可以轻松实现：
发布/订阅：用Fanout。
发任务分发：用Direct配合多个消费者监听同一队列。
选择性接收：用Topic让消费者只接收自己关心的消息。
3.企业级的可靠性保证
RabbitMQ提供了一套完整的可靠链条：
消息持久化：设置delivery_mode=2，并将队列声明为持久的，确保Broker重启后消息不丢失。
生产者确认（PublisherConfirm）：代替事务，Broker会异步告知生产者消息是否已成功处理(写入磁盘)
消费者确认（ConsumerAck）：
自动Ack：消息发出即认为成功，风险高
手动Ack：消费者处理完业务后，手动调用basicAck，Broker才删除消息。这是生产环境的标配。如果处理失败，可以basicNack让消息重新进入队列或者进入死信队列。
坑点与代价：
1.集群模式的“阿喀琉斯之踵”
这是RabbitMQ最需要理解透彻的一点：
普通集群模式：队列元数据在所有节点同步，但队列消息本身只存在于创建它的那个节点。其他节点只是通过元数据找到该节点。这带来了单点瓶颈和单点故障风险。
镜像队列模式：这是解决高可用的方案。你需要在策略中配置ha-mode=all等，将队列镜像到所有节点。
优势：某个节点宕机，客户端可以无缝切换到其他节点数据不丢失。
代价：
性能开销：所有写操作都需要在所有镜像节点间同步，本质是主从复制，不是分布式。这严重限制了写的水平扩展能力。
网络分区(脑裂)风险：当节点间网络出现问题时，RabbitMQ不知道听谁的，会导致脑裂。处理网络分区是运维RabbitMQ集群最头疼的问题之一。
2.性能天花板
单队列性能：大致在几万QPS。如果所有消息都压到一个队列，很容易成为瓶颈。解决方案是使用多个队列，但这有需要你在业务逻辑上做设计。
Erlang GC 的“玄学”问题：在消息量巨大时，Erlang 虚拟机的垃圾回收可能会引起偶发的、难以排查的性能毛刺。
3.消息顺序的“不保证”
默认情况下，如果某个消息因为消费者处理慢或发生 Nack 而被重新投递，它会被放回队列的头部（对于某些版本是尾部），这可能会打乱消息的顺序。
要保证严格顺序，必须：
使用单个消费者。
关闭重试或使用死信队列。这显然会牺牲性能和可靠性。
死信队列：
当消息：
被消费者 Nack 且
requeue=false消息在队列中存活时间（TTL）到期
队列长度达到上限
它会被发送到另一个指定的 Exchange（DLX），进而路由到死信队列。
应用场景：
错误处理：处理失败的消息自动进入死信队列，便于后续排查和重试。
实现延迟消息：创建一个带 TTL 的队列 A，并设置其 DLX 指向一个正常的业务 Exchange。消息在 A 中过期后，会自动转到业务队列被消费。这是 RabbitMQ 实现“30分钟后关闭订单”这类需求的经典方案。
预读计数（PrefetchCount）:
//这是影响消费者性能的关键参数。
// 设置预取计数
channel.setQos(10); // 设置预取计数为10设置为 1：公平分发。Broker 只有在收到上一条消息的 Ack 后，才会发送下一条。确保每个消费者都忙起来，不会出现“能者多劳”的不均衡。
设置较大值：提高吞吐量，但可能导致消费者内存积压，且分发不均。