-
我用消息队列解耦订单处理,以为一条消息只会被消费一次,结果某条扣库存的消息被重复消费了两次,库存莫名其妙被多扣了一份:一次没为消息重复投递做幂等、误把至少一次当成恰好一次的深度复盘
我用消息队列解耦订单流程:订单服务下单发消息,库存服务消费消息扣库存。我想当然地以为一条消息只会被消费一次,消费逻辑写得很直白:收到就扣。线上跑了一阵对账发现少量订单库存被扣了两次——只买 1 件却少了 2 件。翻日志才发现:那几条消息确实被同一个 messageId 消费了两遍。复盘 MQ 投递语义才恍然大悟:绝大多数消息队列默认是至少一次(at-least-once)投递,不是恰好一次(exa…- 0
- 0
-
从单体 PHP 7.4 + LAMP + crontab + 自研 RPC + MySQL 8 主从 → DDD + Hexagonal + CQRS + Event Sourcing + Saga + EDA + Kafka + gRPC + Service Mesh 全栈架构现代化 97 天踩坑录:21 反模式 + 23 修法
37 位架构师 + 高级工程师 97 天把公司"单体应用 + 共享数据库 + 自研 RPC + 同步调用 + 紧耦合业务 + 单库主从"6 大遗留架构整体重构到 2026 年 DDD + Hexagonal + CQRS + Event Sourcing + Saga + EDA + Kafka + gRPC + Istio Ambient + Cilium + 多区域多活,覆…- 3
- 0
-
从 Go 1.22 → 1.24 + chi v6 + Ent + franz-go + Uber FX 全栈现代化 21 天踩坑录:10 反模式 + 13 修法
某 14 微服务集群(日 7.2 亿请求)从 Go 1.22 + chi v5 + GORM v1 + Wire + Kafka segmentio 升级到 Go 1.24 + chi v6 + Ent v0.14 + Uber FX + Kafka franz-go 1.18 + Otel SDK 1.30 + golangci-lint 1.62 + sqlc 1.27。21 天踩 10 个反…- 6
- 0
-
电商订单中心 outbox pattern 双写一致性灰度翻车 11 天复盘:订单消息日均丢 4700 条 + 重复 18000 条 + 乱序 32 次 + 对账差 870 万 + 漏拦欺诈 230 笔——Debezium CDC + 幂等表 + (aggregate_id,sequence) 唯一键 + Kafka transactional.id + Schema Registry 6 套修法 + 13 条事件驱动工程纪律
2026 年 4 月,我们一个电商订单中心(日均 1100 万订单、Spring Boot 3.4 + PostgreSQL 16 + Kafka 3.7 + Debezium 2.6 + 23 个下游消费者:库存、营销、风控、清结算、推荐、客服、BI、对账、物流、CRM、风控审- 3
- 0
-
Saga 分布式事务库存幽灵占用事故复盘:2 个月 47 单灵异库存 + 状态机持久化 + 幂等 + dead-letter 监控三件套
电商订单中台 Saga Orchestration 模式实现里隐藏的 5 个真凶:状态机存内存丢失、补偿幂等用内存 Set 失效、dead-letter 累积 5000+ 条无人监控、支付 timeout 但实际成功导致双扣库存占用、编排者单点。4 天定位 + 5 个月修复,把幽灵库存从月均 23 单压到 0,Saga 失败率从 0.31% 降到 0.04%,沉淀出可复用的分布式事务工程纪律 10…- 4
- 0
-
Kafka 消费幂等性失守导致用户被重复扣款 ¥8.7w 的复盘:6 种幂等方案对比 + Outbox + CDC 落地
大促当晚 Kafka rebalance 触发重复消费,12 位用户被重复扣款,投诉炸了客服。11 天复盘揭开 3 个真凶:auto-commit 在 rebalance 时是定时炸弹、max.poll.interval.ms 超时、支付回调本身不幂等。本文 6 种幂等方案对比、Outbox + Debezium CDC 实战、灰度上线策略、压测脚本、7 条事件驱动纪律。- 6
- 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
-
消息队列完全指南:从一次库存扣三次的事故看懂丢失、重复、顺序怎么治
2023 年我维护一个电商订单系统,用消息队列把下单后的扣库存/加积分/发短信改成异步——订单落库后发一条"订单已创建"消息交给各消费者处理。某次大促运营找来说爆款商品库存对不上:系统显示卖 1200 件实际出库只有 800 多,库存被扣多了。拉扣库存消费者日志顺着一个订单号查,愣住了:同一个订单的"扣库存"消息被消费了三次。我第一反应是"MQ 出…- 2
- 0
-
消费者追不上生产者:一次 Kafka 消息积压的复盘
上游促销订单量翻数倍,Kafka 消费组 lag 涨到数百万还在爬,下游报表停在两小时前。根子是消费并行度被 4 个分区锁死、单条消费 200ms。几天重构消费端:分区与消费者的铁律、扩分区扩消费者、批量消费、rebalance 与 poll 超时、积压紧急追赶与 lag 监控。- 2
- 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
-
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
-
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
-
Kafka 消费幂等 + Offset 管理:2 年踩过的 7 个真实坑
Kafka 文档说 At-least-once,实际生产里 重复消费 是日常。本文 7 个真实坑:auto.offset.commit / 消费跟不上 rebalance / 幂等漏做扣款两次 / 死信队列 / 消息顺序 / 大消息 / 监控指标。每个附 Java + Go 代码 + 核心配置。- 3
- 0
-
Kafka 完全指南:从 Partition 到 ISR 的内部机制
Kafka 是当代分布式系统里最重要的中间件之一 —— 它既是消息队列,也是事件日志、流处理基础设施、数据管道的核心。但很多人对 Kafka 的认知停留在"Producer 发,Consumer 收"。深入到 Topic / Partition / Offset / Consumer Group / Replica / Controller / ISR 这些概念,以及它们怎么协…- 4
- 0
Kafka
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×