RabbitMQ

4 篇文章

堆积预警不是"加机器"就能解决的。这篇给出一套六步应急流程——定位原因、扩容、处理毒消息、限流生产者、优化消费逻辑、事后复盘,并补上扩容后必然出现的乱序问题与两种解法。

订单超时取消是延迟消息最经典的场景。RabbitMQ 原生不支持延迟投递,DLX 方案简单但存在队头阻塞,延迟插件没有阻塞却要动运维。这篇把两种实现的原理解开,并说明消费者为什么必须先查库校验。

消息丢失从来不是某一个组件的问题,而是生产、存储、消费三段里任何一段断了都会丢。这篇逐段拆开讲:本地消息表与 Confirm 怎么配合、Broker 要开哪些持久化、消费者为什么必须手动 ACK。

交换机不是消息的容器,而是路由规则本身。这篇把 Direct 与 Topic 的匹配差异、Fanout 广播、Headers 匹配、备用交换机与死信路由讲清楚,并给出一套选型决策表。