RabbitMQ 消息队列【第37讲：日志收集系统实战】
本文探讨了微服务架构下日志管理的挑战与解决方案。核心问题在于日志分散（多服务、多机器）、格式不统一、存储压力大和实时分析困难。传统 Filebeat 直连 ES 方案存在运维成本高、可靠性差等问题。文章提出采用RabbitMQ作为日志中转站的架构：各服务统一发送结构化日志到 MQ，通过 Topic Exchange 实现分级处理（如*.error触发告警），消费者异步写入 ES。该方案实现了解耦（服务与ES隔离）、削峰（缓冲日志洪峰）、分流（按日志级别路由）和可靠性保障（消息持久化），配合ELK形成完整的日志收集体系
辰风沐阳 阅读 49 2026-07-25
RabbitMQ 消息队列【第36讲：秒杀系统削峰填谷】
本文介绍了如何利用 RabbitMQ 解决秒杀系统的高并发问题。秒杀的难点在于瞬间涌入的流量可能压垮数据库。解决方案采用 Redis 快速判断库存后，将有效请求放入 RabbitMQ 队列，由消费者按可控速度处理订单，实现流量削峰。这使数据库免受瞬时高峰冲击，保证系统稳定。文章包含 PHP 代码示例，展示了从请求处理到结果轮询的完整流程，并总结了 Redis、RabbitMQ 和数据库的分层作用，核心思路是将瞬间流量转化为平稳流量处理。
辰风沐阳 阅读 97 2026-07-24
RabbitMQ 消息队列【第35讲：订单超时自动取消】
电商订单超时自动取消功能的实现方案对比：传统定时任务扫描数据库方式存在延迟高、数据库压力大、扩展性差等问题；而采用 RabbitMQ 的 TTL + 死信队列机制，通过消息过期自动触发取消逻辑，具有实时性强、无数据库压力、扩展灵活等优势。关键实现步骤包括：下单时发送带TTL的消息，消息过期后转入死信队列，消费者处理时校验订单状态并执行原子性取消操作。该方案成为处理延迟任务的经典实践，比传统方案更高效可靠。
辰风沐阳 阅读 86 2026-07-23
RabbitMQ 消息队列【第34讲：异步发送邮件和短信】
本文通过用户注册场景介绍了 RabbitMQ 的应用价值。当注册流程需要同步调用不可控的外部服务（邮件/短信接口）时，会导致响应延迟和流程强耦合。作者对比了传统异步方案（数据库轮询）存在的延迟高、扩展难等问题，提出使用 RabbitMQ 将非核心操作异步化：注册成功后立即返回，通过消息队列实现短信/邮件的可靠投递，支持自动重试。进一步建议使用 Fanout Exchange 实现发布订阅模式，使注册系统与通知系统完全解耦。案例展示了消息队列在异步处理、系统解耦、可靠投递等方面的核心价值，为后续订单超时等复杂场景奠定基础
辰风沐阳 阅读 79 2026-07-22
RabbitMQ 消息队列【第33讲：RabbitMQ 集群部署实战】
本文梳理了 RabbitMQ 集群部署的演进过程：从单机部署（易单点故障）→普通集群（解决连接分散但无数据冗余）→镜像队列（实现数据冗余但存在消息丢失风险）→最终推荐 Quorum Queue（可靠高可用方案）。文章强调理解各阶段解决的问题和局限性比记忆命令更重要，建议生产环境直接采用3节点奇数配置的 Quorum Queue 集群，配合负载均衡和监控。核心在于掌握不同方案的优劣，而非具体部署步骤。
辰风沐阳 阅读 118 2026-07-21
RabbitMQ 消息队列【第32讲：Quorum Queue 仲裁队列】
RabbitMQ 的 Quorum Queue（仲裁队列）是官方推荐的镜像队列替代方案，解决了异步同步导致的消息丢失、主节点瓶颈和脑裂风险三大问题。Quorum Queue 采用多数节点确认机制（如3节点需2个确认），确保消息可靠性和一致性，但需要奇数节点且性能略降。相比镜像队列，它显著提升了数据安全性，成为高可用场景的首选方案，尤其适合订单支付等关键业务，不过不支持优先级队列等部分高级功能。
辰风沐阳 阅读 75 2026-07-20
RabbitMQ 消息队列【第31讲：镜像队列是什么】
本文介绍了 RabbitMQ 镜像队列的工作原理和特点。镜像队列通过将队列数据复制到多个节点实现高可用，包含一个主节点（负责读写）和多个镜像节点（负责备份）。当主节点故障时，系统会自动选择镜像节点接替。配置通过 Policy 实现，可选择全部或部分节点进行镜像。然而镜像队列存在性能开销大、主节点瓶颈、故障转移可靠性不足以及集群状态不一致风险等问题。正因如此，RabbitMQ 3.8 版本推出了 Quorum Queue 作为其替代方案。
辰风沐阳 阅读 88 2026-07-19
RabbitMQ 消息队列【第30讲：普通集群模式】
本文介绍了 RabbitMQ 普通集群的特点和局限性。普通集群通过多节点共享元数据实现连接分散，减轻单机压力，但队列数据仅存储在声明节点上，不具备数据冗余能力。当队列所在节点宕机时，该队列将不可用。因此普通集群只能解决连接分散问题，无法实现真正的高可用。文章通过具体场景说明这个容易被误解的特性，并指出要实现高可用需要使用镜像队列（将在下篇文章介绍）。关键结论：普通集群是"能用"而非"高可用"的解决方案。
辰风沐阳 阅读 98 2026-07-18
RabbitMQ 消息队列【第29讲：为什么需要集群】
本文分析了 RabbitMQ 单机部署的三大风险：单点故障导致系统全停、单机性能容量瓶颈、无法应对流量洪峰。通过集群部署可以分散连接和存储压力，实现节点故障时系统仍可工作。但普通集群模式下，队列数据仍只存储在一个节点上，该节点故障时队列仍不可用。文章指出集群虽能提升可用性和扩展性，但普通集群方案存在局限性，无法彻底解决高可用问题，为后续讲解更完善的集群方案做铺垫。
辰风沐阳 阅读 85 2026-07-17
RabbitMQ 消息队列【第28讲：消息追踪与问题排查】
用户投诉下单后未收到短信通知，排查发现订单数据正常但消息丢失。RabbitMQ 消息流转涉及 Producer→Exchange→Queue→Consumer 多个环节，需逐层排查。建议优先通过 Producer/Consumer 日志、RabbitMQ 管理界面（检查Exchange/Queue状态）定位问题，常见问题包括路由错误、队列名不符、未ACK等。复杂场景可使用 Tracing 插件追踪消息轨迹，但多数问题通过常规工具即可解决。核心思路是沿消息流向有序排查，优先验证代码和配置而非中间件本身。
辰风沐阳 阅读 90 2026-07-16