-
一个没做幂等的消息队列消费者,因为一次网络抖动把同一条扣款消息消费了两次,给用户活生生扣了两次钱:一次消息重复消费与幂等缺失的深度复盘
半夜被叫醒处理资损:一笔订单被扣了两次款,有两条几乎一致的扣款流水,可同一笔订单我们只发了一条扣款消息。翻 MQ 投递日志才看清:消息队列是 at-least-once(至少一次)投递、宁可重复不愿丢消息,那次扣款服务已成功扣款,但返回 ack 时网络抖动、ack 没送达,MQ 以为没处理成功便重新投递,而消费者没做幂等、又扣了一次。本文讲透 MQ 三种投递语义与为何必须幂等,给出数据库唯一约束/…- 0
- 0
-
一条扣款消息被消费了两次、用户被重复扣了钱,我查遍代码逻辑都没错、消息也确实只发了一条,我对着幂等性缺失和消息重投排查了大半天的复盘
半夜被电话叫醒的线上事故:有用户一笔订单被扣了两次钱。翻遍扣款逻辑没有任何会扣两次的分支,查消息队列确认上游那条扣款消息确实只发了一条。一条消息、一段没错的代码,怎么就扣了两次?排查大半天才理解分布式系统最易被忽略却最致命的设计缺失——幂等性,以及 MQ "至少投递一次"这个我从没认真对待的特性。事故链条是:消费者成功扣款,但 ACK 确认时网络抖动/重启导致 ACK 丢失,M…- 0
- 0
-
用户下了单没收到短信、买了东西积分没加,订单明明下单成功后续处理却像从来没发生过一样凭空消失:消息队列消息丢失的端到端可靠性避坑复盘
这是一个东西凭空消失的事故而且消失得无声无息直到用户投诉才暴露。我们用消息队列做订单的异步后续处理,用户下完单主流程往 MQ 里发一条消息然后下游的消费者收到消息去做那些不那么紧急的后续事发短信通知给用户加积分同步给其它系统。这套用 MQ 解耦异步的架构很常见也很优雅,可上线一段时间后陆续有用户反馈:我下了单怎么没收到短信?我买了东西积分怎么没加?而去查订单本身是好好的下单成功了,可那些后续处理有…- 3
- 0
-
Kafka 消息队列工程化完全指南:从一次"acks=1 丢 3000 单订单损失 50 万"看懂为什么 send/poll 远远不够
2021 年我加入一家直播带货公司接手订单系统当时下单链路是用户下单写 MySQL 同步调库存调营销调通知调推送 5 个下游服务每个 100ms 端到端 500ms 直播间瞬时下单峰值 8000 QPS 链路雪崩我决定引入 Kafka 把下游全异步化觉得 Kafka 高吞吐低延迟上 3 broker 8 partition 应该够用改造后压测确实漂亮 8000 QPS 端到端 50ms 老板很满意…- 0
- 0
-
消息队列完全指南:从一次"异步下单后积分没加、还重复扣了款"看懂可靠消息投递
2023 年我做一个电商的下单系统。下单成功后要做一连串事发短信通知给用户加积分通知仓库发货更新销量统计。第一版我做得很直接在下单接口里一件接一件同步地调结果接口慢得感人。我很快想到用消息队列下单成功后只往 MQ 里发一条订单已创建的消息就立刻返回后面那些活交给消费者异步处理接口快得飞起。我心里很踏实消息发出去了后面的事自然有人处理。可上线之后客服的投诉一条接一条第一类用户明明下单成功了积分却没加…- 2
- 0
MQ
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×