-
我用消息队列解耦订单处理,以为一条消息只会被消费一次,结果某条扣库存的消息被重复消费了两次,库存莫名其妙被多扣了一份:一次没为消息重复投递做幂等、误把至少一次当成恰好一次的深度复盘
我用消息队列解耦订单流程:订单服务下单发消息,库存服务消费消息扣库存。我想当然地以为一条消息只会被消费一次,消费逻辑写得很直白:收到就扣。线上跑了一阵对账发现少量订单库存被扣了两次——只买 1 件却少了 2 件。翻日志才发现:那几条消息确实被同一个 messageId 消费了两遍。复盘 MQ 投递语义才恍然大悟:绝大多数消息队列默认是至少一次(at-least-once)投递,不是恰好一次(exa…- 0
- 0
-
一个没做幂等的消息队列消费者,因为一次网络抖动把同一条扣款消息消费了两次,给用户活生生扣了两次钱:一次消息重复消费与幂等缺失的深度复盘
半夜被叫醒处理资损:一笔订单被扣了两次款,有两条几乎一致的扣款流水,可同一笔订单我们只发了一条扣款消息。翻 MQ 投递日志才看清:消息队列是 at-least-once(至少一次)投递、宁可重复不愿丢消息,那次扣款服务已成功扣款,但返回 ack 时网络抖动、ack 没送达,MQ 以为没处理成功便重新投递,而消费者没做幂等、又扣了一次。本文讲透 MQ 三种投递语义与为何必须幂等,给出数据库唯一约束/…- 0
- 0
-
一条扣款消息被消费了两次、用户被重复扣了钱,我查遍代码逻辑都没错、消息也确实只发了一条,我对着幂等性缺失和消息重投排查了大半天的复盘
半夜被电话叫醒的线上事故:有用户一笔订单被扣了两次钱。翻遍扣款逻辑没有任何会扣两次的分支,查消息队列确认上游那条扣款消息确实只发了一条。一条消息、一段没错的代码,怎么就扣了两次?排查大半天才理解分布式系统最易被忽略却最致命的设计缺失——幂等性,以及 MQ "至少投递一次"这个我从没认真对待的特性。事故链条是:消费者成功扣款,但 ACK 确认时网络抖动/重启导致 ACK 丢失,M…- 0
- 0
-
每天总有那么几个订单,消息明明发出去了、却像人间蒸发了一样没被处理:我在消息队列里栽进的"自动确认导致消息丢失"的坑的深度复盘
用 MQ 做异步处理,可财务对账发现每天总有极少数订单的消息明明发出去了、消费者却没有任何处理记录——像人间蒸发了。根因是消费者用了自动确认(auto-ack):消息一收到 MQ 就当它"处理成功"删掉了,可"收到"不等于"处理完",消费者一旦在处理到一半时崩溃,消息就被永久丢失。这篇从 ack 确认机制讲到手动确认+消费者幂等的正解、消…- 0
- 0
-
用户下了单没收到短信、买了东西积分没加,订单明明下单成功后续处理却像从来没发生过一样凭空消失:消息队列消息丢失的端到端可靠性避坑复盘
这是一个东西凭空消失的事故而且消失得无声无息直到用户投诉才暴露。我们用消息队列做订单的异步后续处理,用户下完单主流程往 MQ 里发一条消息然后下游的消费者收到消息去做那些不那么紧急的后续事发短信通知给用户加积分同步给其它系统。这套用 MQ 解耦异步的架构很常见也很优雅,可上线一段时间后陆续有用户反馈:我下了单怎么没收到短信?我买了东西积分怎么没加?而去查订单本身是好好的下单成功了,可那些后续处理有…- 3
- 0
-
大促后对账发现重复扣款:一篇讲透接口幂等性设计
大促结束后的第二天上午,财务一条"对账对不平、几十个用户被重复扣款"的消息把我从复盘的轻松里一把拽出来,更夸张的是有人同一笔订单在库里躺着三四条记录。复盘下来真相平淡得后背发凉:流量冲顶时下单接口变慢,用户疯狂连点,客户端和网关又都配了超时重试,同一个请求被结结实实送进后端好几遍——而整个下单链路没有任何一处做了幂等保护。这篇文章从那次重复扣款事故出发,把接口幂等设计从头讲透:…- 8
- 0
-
订单系统抗大促架构演进:异步削峰、库存预扣、服务拆分与最终一致性
那年第一次参加大促,我们的订单系统在活动开始后第四分钟就崩了:下单成功率从 99% 直线跳水到不足 30%,数据库连接瞬间打满、CPU 飙到 100%,连商品详情、购物车这些跟下单八竿子打不着的页面也跟着转圈(因为共用一个库被一起拖下水),事后还清出上百个超卖订单要连夜退款道歉,几个人守到凌晨三点才勉强稳住。复盘结论很清楚:不是机器不够,是架构扛不住瞬时洪峰——一个平时跑得好好的同步串行单体,在「…- 2
- 0
-
Kafka 消费者组与 exactly-once 完全指南:从一次"Pod OOM 重启 rebalance 后 12 万条对账重复消费财务通宵对账"看懂为什么 enable.auto.commit=true 远远不够
2023 年我们做一个支付对账系统上游 Kafka 推支付成功消息下游消费写入对账库第一版用 Spring Kafka 默认配置 enable auto commit true 跑得飞起老板说 Kafka 这么稳上线第一周就出大事一次 Pod OOM 重启消费者重新加入 group 触发 rebalance offset 提交跟消费处理时序错位一批已经写入对账库的消息被重复消费财务对账多出 12 …- 0
- 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
-
Kafka 消息可靠性工程化完全指南:从一次"机房故障 200 条订单消息丢失"看懂为什么默认配置远远不够
2023 年我们公司有一套订单系统上游产生事件下游有 6 个消费服务用 Kafka 做异步消息总线一开始我接手时配置很标准 3 个 broker 默认 partition 数 ack=1 producer 自动批 consumer auto-commit 看起来该有的都有测试环境跑得也挺顺但上线半年我们陆续踩了一堆坑第一种最让我傻眼某次机房故障一个 broker 挂了我以为副本机制应该自动转结果有…- 0
- 0
-
Kafka 消费者组与 rebalance 工程实战:从一次"凌晨 3 点整组消费停顿 20 分钟"看懂为什么慢消息能拖垮你的消费链路
2023 年我接手了一套基于 Kafka 的订单事件处理链路上游一天大概几亿条事件下游有十几个消费者组各自处理不同业务接手的第一个月一切都很顺没出什么大事让我心里很笃定 Kafka 这东西嘛只要 topic 分区数够多消费者数量配得上就完事了直到有一天凌晨 3 点告警群里炸了订单状态回写延迟从平时的 200 毫秒涨到了 40 秒我爬起来排查发现下游某个消费者组在不停 rebalance 平均每 3…- 2
- 0
-
消息队列幂等完全指南:从一次"积分被加了三次,库存被多扣"看懂 at-least-once 与重复消费
2022 年我给一个电商订单系统接消息队列用户下单后扣库存加积分发通知短信这些后续动作全部丢进 MQ 异步去做怎么消费这些消息这件事我压根没多想第一版我做得很顺手消费者从队列里取一条消息该扣库存扣库存该加积分加积分处理完了 ack 确认一下就完事了本地拿一批消息一测真不错下一单消费一条库存减一积分加上分毫不差我心里很笃定消息队列嘛我发一条消费者收一条处理一条一条消息对应一次处理 MQ 这种成熟中间…- 0
- 0
-
消息队列完全指南:从一次"异步下单后积分没加、还重复扣了款"看懂可靠消息投递
2023 年我做一个电商的下单系统。下单成功后要做一连串事发短信通知给用户加积分通知仓库发货更新销量统计。第一版我做得很直接在下单接口里一件接一件同步地调结果接口慢得感人。我很快想到用消息队列下单成功后只往 MQ 里发一条订单已创建的消息就立刻返回后面那些活交给消费者异步处理接口快得飞起。我心里很踏实消息发出去了后面的事自然有人处理。可上线之后客服的投诉一条接一条第一类用户明明下单成功了积分却没加…- 2
- 0
-
消息队列削峰完全指南:从一次"秒杀活动瞬间把数据库打挂"看懂异步削峰
2021 年我做一个电商的秒杀功能。第一版做得很直白:用户点立即抢购,后端就同步地把这一整套流程跑完——校验库存、扣减库存、创建订单、写订单表、扣用户余额,全部做完才给前端返回抢购成功。平时测试一切正常响应飞快。可活动真正开始的那一秒系统崩了:活动开始前接口每秒几十个请求,活动开始那一刻每秒请求数瞬间冲到几万,这几万个请求每一个都触发了那套同步流程同时挤进数据库,连接池瞬间被占满,后面的请求全部排…- 0
- 0
-
消息队列完全指南:从一次库存扣三次的事故看懂丢失、重复、顺序怎么治
2023 年我维护一个电商订单系统,用消息队列把下单后的扣库存/加积分/发短信改成异步——订单落库后发一条"订单已创建"消息交给各消费者处理。某次大促运营找来说爆款商品库存对不上:系统显示卖 1200 件实际出库只有 800 多,库存被扣多了。拉扣库存消费者日志顺着一个订单号查,愣住了:同一个订单的"扣库存"消息被消费了三次。我第一反应是"MQ 出…- 2
- 0
-
消费者追不上生产者:一次 Kafka 消息积压的复盘
上游促销订单量翻数倍,Kafka 消费组 lag 涨到数百万还在爬,下游报表停在两小时前。根子是消费并行度被 4 个分区锁死、单条消费 200ms。几天重构消费端:分区与消费者的铁律、扩分区扩消费者、批量消费、rebalance 与 poll 超时、积压紧急追赶与 lag 监控。- 2
- 0
-
消息消费失败后悄悄没了:一次死信队列治理的复盘
积分异步发放,一条消息消费失败后,requeue=true 把队列卡成死循环,requeue=false 又让消息无声消失。根子是从没为失败消息设计归宿。几天补齐:死信与 DLX、死信交换机配置、失败分类、延迟重试队列、消费端幂等、死信监控与重投流程。- 0
- 0
-
消息积压三百万:一次 Kafka 消费积压与重复消费的复盘
大促那天 Kafka consumer lag 从几百飙到三百万,履约系统延迟数小时;扩容后又冒出重复发货短信。一边积压一边重复,是消费端最经典的一对矛盾。几天消息消费专项治理:看懂 lag 与消费模型、关自动提交做消费端幂等、防消息丢失、批量与并发提吞吐、rebalance 治理、lag 监控。- 0
- 0
-
Kafka 消费者陷入 rebalance 风暴:消息积压与重平衡治理实录
用户行为日志走 Kafka,某天消费组 Lag 从几百暴涨到 1800 万,消费者满屏 rebalance 几乎不消费。一周消费端治理:理清两套存活判定、减小 max.poll.records、Cooperative rebalance、消费/处理线程分离、手动提交 offset + 幂等、扩分区消化积压。Lag 稳定千级。- 0
- 0
-
订单消息一会丢一会重:RocketMQ 消息可靠性与消费幂等实战
订单系统用 RocketMQ 异步解耦,对账发现每天 230 笔积分消息丢失、80 笔重复。两周治理:生产端事务消息 + 本地消息表 + 同步发送检查;broker 端 SYNC_FLUSH + SYNC_MASTER;消费端唯一索引 + 状态机幂等 + 死信补偿 + 顺序消息。连续 3 个月对账零差异。- 0
- 0
-
Kafka 集群春节大促雪崩复盘:partition 均衡 + 生产消费 + 监控告警实录
Kafka 3.4 KRaft 集群 9 broker 1.5w partition,春节大促 NotLeaderForPartition 暴增,lag 2000w,Controller 切换频繁。两周治理:partition 重均衡 + idempotence + acks=all + max.poll 500 + ISR 限速 + 全链路监控。P99 50ms,lag < 1000,稳过…- 6
- 0
-
RocketMQ 月丢 387 笔订单事故复盘:零丢失零重复消费全链路修法
月度对账发现订单库少 387 笔但支付库正常,根因 RocketMQ 异步刷盘 + oneway + 无事务消息 + 消费无幂等多重叠加。两周治理:SYNC_MASTER + 同步发送 + 事务消息 half/commit + Redis setnx + 唯一索引 + DLQ 监控 + MessageTrace 全链路可查。月丢失 0,重复消费 0。- 2
- 0
-
Kafka 5000w Lag 8 小时事故复盘:消费端优化全实录
Kafka 大流量回放事故复盘:3000w 消息 10min 涌入,Lag 5000w 不收敛延迟 8 小时。优化全实录:partition 12→64 + batchListener + saveBatch + 内部并发分组 + DLQ + RateLimiter + 全链路监控。Lag 从 5000w 在 40min 归零,QPS 10w→160w。- 2
- 0
-
Kafka 顺序消费的 7 层防线:订单状态错乱事故复盘
已取消订单又变成已支付:Kafka 顺序消费错乱复盘。本文讲透 7 层防线:Producer 幂等 + Partition 路由 + 扩容稳定 + Consumer 单线程模型 + key-based 并发 + 手动 offset + 失败暂停 partition + 业务层 last_event_ts 兜底。附完整 Java 代码 + 故障注入验证。- 2
- 0
消息队列
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×