RabbitMQ 消息队列【第20讲：Headers Exchange 头匹配】
本文介绍了 RabbitMQ 中的 Headers Exchange，它通过消息头属性（headers）而非路由键（routing key）进行消息路由，支持多维度键值对匹配，提供 all（全匹配）和 any（任一匹配）两种模式。相比 Topic Exchange，Headers Exchange 灵活性更高但性能较差，实际使用频率较低，仅适用于消息维度复杂、需多属性组合匹配的场景。文中对比了四种 Exchange 类型：Direct（精确匹配）、Fanout（广播）、Topic（通配符匹配）和 Headers（属性匹配）
辰风沐阳 阅读 113 2026-07-07
RabbitMQ 消息队列【第19讲：Topic Exchange 通配符路由】
本文介绍了 RabbitMQ 的 Topic Exchange 模式。该模式通过通配符匹配规则实现灵活的消息路由，解决了 Direct Exchange 精确匹配和 Fanout Exchange 全量广播的局限性。 核心要点： 通配符规则： *匹配一个词（如*.error匹配order.error） #匹配多个词（如order.#匹配order.error/order.info等） 典型应用场景： 日志分级收集系统 按模块/类型批量分发消息 需要灵活路由规则的业务场景
辰风沐阳 阅读 124 2026-07-06
RabbitMQ 消息队列【第18讲：Fanout Exchange 广播模式】
本文介绍了 RabbitMQ 的 Fanout Exchange 模式，适用于需要广播消息的场景。与 Direct Exchange 的精确投递不同，Fanout Exchange 会将消息无条件转发给所有绑定的队列，无需指定路由键。典型应用如用户注册后同时触发邮件、优惠券发放和数据分析等操作。文章通过 PHP 代码演示了 Fanout Exchange 的声明、队列绑定和消息发布流程，并对比了 Fanout 和 Direct 两种模式的特点：Fanout 实现"一发多收"的广播机制，而 Direct 则是"精确投递"。
辰风沐阳 阅读 122 2026-07-05
RabbitMQ 消息队列【第17讲：Direct Exchange 精确匹配】
本文介绍了 RabbitMQ 中 Direct Exchange（直连交换机）的使用场景和实现方式。Direct Exchange 通过精确匹配路由标识实现消息的精准投递，适用于需要严格区分消息类型的场景，如日志分级处理系统。文章通过 PHP 代码示例展示了如何声明 Direct Exchange、绑定队列（error_queue、warning_queue、info_queue）并指定路由键（error/warning/info），实现不同级别日志的定向分发。
辰风沐阳 阅读 116 2026-07-04
RabbitMQ 消息队列【第16讲：Exchange 到底是什么】
本文围绕 RabbitMQ 交换机 Exchange 展开讲解，先通过电商下单场景分析生产者直接向多队列发送消息存在耦合严重、代码冗余、灵活性不足等缺陷；随后介绍 Exchange 的核心价值：作为生产者与队列的中间层，生产者仅将消息发送至交换机，由交换机依据对应规则完成消息路由分发。文中阐述 Exchange 两大核心工作流程，并梳理 Direct、Fanout、Topic、Headers 四种交换机的不同匹配路由规则；最终总结使用 Exchange 可解耦生产者与队列，新增或调整下游队列无需修改生产者代码，统一管理消息路由逻辑，区分生产者 “发送消息”、交换机 “分发消息” 的职责，文末预告下一讲将讲解 Direct 交换机。
辰风沐阳 阅读 150 2026-07-03
RabbitMQ 消息队列【第15讲：消息除了内容还能携带什么信息】
本文介绍了 RabbitMQ 消息的属性机制，重点解析了消息的"快递单"功能。文章首先通过类比快递包裹，说明消息除了业务数据(body)外，还能通过属性(properties)传递元信息。详细讲解了两个核心属性：delivery_mode (投递模式，控制消息持久化) 和 content_type (内容类型，指定消息体格式)，并给出 PHP 代码示例。此外还列举了其他可选属性如优先级、过期时间等。最后指出消费者可以读取这些属性信息，并预告后续将讲解 Exchange 交换机的相关内容。全文强调了消息属性对消息处理方式的重要影
辰风沐阳 阅读 186 2026-07-02
RabbitMQ 消息队列【第14讲：RabbitMQ 重启之后消息还在吗】
RabbitMQ 重启后消息默认会丢失，因为消息默认存储在内存中。要确保消息持久化，需要同时配置队列持久化和消息持久化：声明队列时设置 durable=true，发送消息时设置 delivery_mode=PERSISTENT。结合手动 ACK 机制，这三者构成了 RabbitMQ 消息可靠性的基础保障。但需要注意，持久化仍无法应对极端情况如磁盘损坏。对于大多数业务场景，这种组合已能满足需求，而高可靠性场景可进一步使用发布确认机制。
辰风沐阳 阅读 209 2026-07-01
RabbitMQ 消息队列【第13讲：消费者处理到一半挂了怎么办】
本文介绍了 RabbitMQ 的两种消息确认模式：自动确认和手动确认。自动确认模式下，消息一旦发送即被删除，若消费者处理失败会导致消息丢失；手动确认模式下需消费者显式调用 ack()，若消费者崩溃未确认，消息会重新入队。文章通过短信发送场景说明自动确认的风险，并给出 PHP 代码示例展示如何开启手动确认（设置 no_ack=false 后调用 ack()）。核心结论是重要业务必须使用手动确认模式以确保消息可靠性。文末对比了两种模式的优缺点，并预告将讨论 RabbitMQ 持久化问题。
辰风沐阳 阅读 235 2026-07-01
RabbitMQ 消息队列【第12讲：什么是 Consumer 消费者】
本文介绍了 RabbitMQ 中消费者（Consumer）的核心特性与工作原理。消费者作为消息处理端，需保持常驻运行状态，通过"推模式"被动接收消息，而非主动轮询队列。与生产者（Producer）相比，消费者具有持续运行、被动接收、多实例并行等特点，类似外卖平台中持续待命的骑手。文章还指出消费者宕机不会导致消息丢失（具体容错机制将在下期详解），并强调了正确实现消费者应避免低效的轮询方式。核心结论是：生产者负责瞬时发送消息，消费者则需长期值守处理消息。
辰风沐阳 阅读 194 2026-06-30
RabbitMQ 消息队列【第11讲：什么是 Producer 生产者】
本文介绍了 RabbitMQ 中 Producer 的基本概念和工作原理。Producer 负责将消息发送到 RabbitMQ 中，主要完成三个步骤：连接 RabbitMQ、将消息告知 Exchange、发送消息后立即关闭连接。通过 PHP 示例代码展示了 Producer 的具体实现方式，并强调了 Producer 是一个短命程序，发送完消息后即结束，不需要关心消息的后续处理。与 Consumer 不同，Producer 不负责消息的存储和消费过程，其核心职责仅是发送消息。
辰风沐阳 阅读 166 2026-06-30