同事甩给我一个跑了 25 分钟的同步接口 上周三下午，做商品中心的小赵在工位上喊我："哥，我这个批量生成接口本地跑得好好的，一上预发就 504，你帮我看看。" 需求不复杂：运营上传一个 5000 行的商品 Excel，每行调一次大模型生成营销文案，全跑完导出结果文件。他写的是同步接口，一个 for
事故：用户收到两笔重复的退款 五一后第一天，客服转来一个投诉：同一笔订单退了两次款。查 MQ 消费日志，发现退款消息被消费了两次。RocketMQ 的「至少一次」投递语义意味着重复消费必然发生，幂等没做好的锅，得我们自己背。 排查：为什么恰好重复 消息体里其实带了唯一的 refundId，但旧代码直
每天 300 万条的对账 财务对账原来用 crontab + 一个 main 方法跑，失败了从头来，半夜崩了没人管。最惨的一次，任务跑到一半数据库连接断了，已处理的 150 万条没记录，重跑又重复处理了一遍，对账差了几十万。换成 Spring Batch 后，断点续跑和重试才真正可控，凌晨的 job
对账群里跳出一条消息：同一笔订单扣了两次款 2 月 19 号下午，财务在对账时发现一笔订单出现了两次支付成功记录，金额都是 199 元。看起来是消费者把消息重复处理了。 我们用的 Kafka 是 3.1.0，消费者是 enable.auto.commit=true 默认配置。同事问我：不是说 Kaf
告警：0 点 15 分，堆积 1200 万 8 月 31 号晚上大促，我们值守到凌晨。0 点 15 分，告警响了： [P1] RocketMQ consumer lag: group=order-sync-consumer, topic=ORDER_SYNC_TOPIC diff=1,20
需求：30 分钟未支付自动关单 产品提了个很常见的需求：用户下单后 30 分钟没支付，自动关闭订单并释放库存。我们日均订单 12 万，粗略统计落在 30 分钟窗口内未支付的约 3.4 万单。 这个需求本质是"延迟任务"，实现方式有好几种，我基本都试过，把各自的坑记一下。 方案一：定时扫表 最朴素的写
同事问：订单状态怎么倒着走了 做微服务改造时，订单状态变更要通过 MQ 广播给下游（积分、优惠券、物流、通知）。上线一周后，物流组的同事找过来："你们发的消息顺序不对，我这边先收到'已发货'，后收到'已付款'，状态机直接报错。" 我看了一眼他的日志，确实是反的： 14:03:21.114 收到订单消
财务对账少了 38 笔，消息不知道去哪了 1 月 10 号早上，财务那边甩过来一张表：12 月的积分发放记录比订单表少了 38 笔。我们发积分是下单成功后发一条 ORDER_PAID_TOPIC，积分服务消费它加积分。订单在，积分没加，说明消息在中途没了。 38 笔，占当月 47 万订单的万分之零点
短信服务商挂了 23 分钟，我们丢了 1247 单 那是去年 11 月的事。我们合作的短信服务商机房故障，接口全部超时。按理说短信发不出去不是什么大事，但那天下单成功率从 99.9% 掉到了 63%，23 分钟里少成交了 1247 单。 原因很简单：下单接口里同步调用了发短信，短信服务超时 30 秒
