同事甩给我一个跑了 25 分钟的同步接口 上周三下午,做商品中心的小赵在工位上喊我:"哥,我这个批量生成接口本地跑得好好的,一上预发就 504,你帮我看看。" 需求不复杂:运营上传一个 5000 行的商品 Excel,每行调一次大模型生成营销文案,全跑完导出结果文件。他写的是同步接口,一个 for
事故:用户收到两笔重复的退款 五一后第一天,客服转来一个投诉:同一笔订单退了两次款。查 MQ 消费日志,发现退款消息被消费了两次。RocketMQ 的「至少一次」投递语义意味着重复消费必然发生,幂等没做好的锅,得我们自己背。 排查:为什么恰好重复 消息体里其实带了唯一的 refundId,但旧代码直
告警: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 收到订单消
短信服务商挂了 23 分钟,我们丢了 1247 单 那是去年 11 月的事。我们合作的短信服务商机房故障,接口全部超时。按理说短信发不出去不是什么大事,但那天下单成功率从 99.9% 掉到了 63%,23 分钟里少成交了 1247 单。 原因很简单:下单接口里同步调用了发短信,短信服务超时 30 秒