-
一个没做幂等的消息队列消费者,因为一次网络抖动把同一条扣款消息消费了两次,给用户活生生扣了两次钱:一次消息重复消费与幂等缺失的深度复盘
半夜被叫醒处理资损:一笔订单被扣了两次款,有两条几乎一致的扣款流水,可同一笔订单我们只发了一条扣款消息。翻 MQ 投递日志才看清:消息队列是 at-least-once(至少一次)投递、宁可重复不愿丢消息,那次扣款服务已成功扣款,但返回 ack 时网络抖动、ack 没送达,MQ 以为没处理成功便重新投递,而消费者没做幂等、又扣了一次。本文讲透 MQ 三种投递语义与为何必须幂等,给出数据库唯一约束/…- 0
- 0
-
每天总有那么几个订单,消息明明发出去了、却像人间蒸发了一样没被处理:我在消息队列里栽进的"自动确认导致消息丢失"的坑的深度复盘
用 MQ 做异步处理,可财务对账发现每天总有极少数订单的消息明明发出去了、消费者却没有任何处理记录——像人间蒸发了。根因是消费者用了自动确认(auto-ack):消息一收到 MQ 就当它"处理成功"删掉了,可"收到"不等于"处理完",消费者一旦在处理到一半时崩溃,消息就被永久丢失。这篇从 ack 确认机制讲到手动确认+消费者幂等的正解、消…- 0
- 0
-
消息队列幂等完全指南:从一次"积分被加了三次,库存被多扣"看懂 at-least-once 与重复消费
2022 年我给一个电商订单系统接消息队列用户下单后扣库存加积分发通知短信这些后续动作全部丢进 MQ 异步去做怎么消费这些消息这件事我压根没多想第一版我做得很顺手消费者从队列里取一条消息该扣库存扣库存该加积分加积分处理完了 ack 确认一下就完事了本地拿一批消息一测真不错下一单消费一条库存减一积分加上分毫不差我心里很笃定消息队列嘛我发一条消费者收一条处理一条一条消息对应一次处理 MQ 这种成熟中间…- 0
- 0
-
消息队列完全指南:从一次"异步下单后积分没加、还重复扣了款"看懂可靠消息投递
2023 年我做一个电商的下单系统。下单成功后要做一连串事发短信通知给用户加积分通知仓库发货更新销量统计。第一版我做得很直接在下单接口里一件接一件同步地调结果接口慢得感人。我很快想到用消息队列下单成功后只往 MQ 里发一条订单已创建的消息就立刻返回后面那些活交给消费者异步处理接口快得飞起。我心里很踏实消息发出去了后面的事自然有人处理。可上线之后客服的投诉一条接一条第一类用户明明下单成功了积分却没加…- 2
- 0
-
消息消费失败后悄悄没了:一次死信队列治理的复盘
积分异步发放,一条消息消费失败后,requeue=true 把队列卡成死循环,requeue=false 又让消息无声消失。根子是从没为失败消息设计归宿。几天补齐:死信与 DLX、死信交换机配置、失败分类、延迟重试队列、消费端幂等、死信监控与重投流程。- 0
- 0
RabbitMQ
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×