-
我把一个下单操作拆成了先调库存服务扣库存、再调订单服务建订单,本地测试一路绿灯,可上线后偶尔出现库存扣了、订单却没建成,钱货两空、数据对不上,排查半天才明白跨服务的操作根本没有我以为的那种原子性的深度复盘
我做了个下单流程涉及两个独立微服务:库存服务和订单服务,代码很直白——第一步调库存服务扣库存,第二步调订单服务建订单。本地测试两步都顺利,我便觉得天衣无缝。可上线后客服陆续收到投诉:有用户下单失败可库存却被扣了;对账也发现库存扣减记录和实际订单数对不上,有批库存凭空少了却找不到对应订单。翻日志真相浮现:这些异常都是第一步扣库存成功了、第二步建订单失败了(订单服务超时/宕机/网络抖),第一步已实实在…- 2
- 0
-
钱扣了订单却没了:微服务分布式事务避坑复盘
一次让我至今心有余悸的线上事故:下单流程被拆成订单、库存、账户三个微服务依次配合,上线后大多风平浪静,某天财务对账却发现一笔诡异记录——用户的钱被扣了、库存也减了,订单却不存在,客服电话被打爆。扒日志还原现场才明白:那次请求账户成功扣款、库存成功减货,轮到最后写订单时,订单服务的机器恰好抖了一下、数据库连接超时,订单没写成,而前两步已经木已成舟,谁来还?在单体里这三步本可包在一个本地事务里要么全成…- 0
- 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
-
下了单库存没扣:一次分布式事务踩坑的复盘
单体电商拆成微服务后,订单/库存/账户各连各的库,下单成功了库存却没扣、对账账实不符。根子是 @Transactional 只管单库,跨服务的一致性数据库再也管不了。几天把分布式事务方案彻底搞清:2PC/XA、TCC 三段式、本地消息表、MQ 事务消息、Saga、Seata AT 模式与选型。- 0
- 0
-
分布式事务踩坑:服务拆分后订单成功库存却没扣的复盘
服务拆分后订单、库存、积分各自独立数据库,对账发现一批订单创建成功了但库存没扣。根因是 @Transactional 只管本地单库,跨服务操作毫无事务保障。两周治理:认清本地事务边界、本地消息表、RocketMQ 事务消息、TCC 强一致、Seata AT 低侵入,以及方案选型与对账兜底。- 0
- 0
-
分布式事务完全指南:从 2PC 到 TCC、Saga 与消息事务
"用户下单要扣库存、扣余额、加积分,这三件事必须同时成功或同时失败。在单库里 BEGIN-COMMIT 就行;但库存在 A 服务,余额在 B 服务,积分在 C 服务 —— 怎么办?" 这就是分布式事务问题。它没有单库 ACID 那么干净的答案 —— 所有方案都是在一致性、可用性、性能之间的精心折衷。这篇文章把 2PC、3PC、TCC、Saga、消息事务讲透,讲清楚每种方案的适用…- 0
- 0
分布式事务
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×