Mall on Fallensakura715's Blog

订单幂等与支付回调改造

Thu, 15 Oct 2026 15:31:28 +0800

原项目的问题

原单体项目把订单服务拆出来后有几问题。

重复下单

原来的下单流程，每次执行generateOrder()，最终总会调用orderMapper.insert(order);，它没有识别这个请求是否曾经处理过，同一笔订单，重试一次就会多创建一次。
订单状态相互覆盖

如果支付和取消同时发生，后来的操作会覆盖前面的状态。订单刚支付完就有个取消请求，订单就会被直接取消，没有退款流程或者支付成功状态。

即：取消请求查到：订单待付款 -> 支付请求把订单改成已支付 -> 取消请求继续执行，把订单覆盖成已关闭。先查过待付款不能保证更新时仍然待付款。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


public void cancelOrder(Long orderId) { 
 //查询未付款的取消订单 
 OmsOrderExample example = new OmsOrderExample(); 
 example.createCriteria()
		 .andIdEqualTo(orderId)
			.andStatusEqualTo(0)
			.andDeleteStatusEqualTo(0); 
 List<OmsOrder> cancelOrderList = orderMapper.selectByExample(example); 
 if (CollectionUtils.isEmpty(cancelOrderList)) { 
 return; 
 } 
 OmsOrder cancelOrder = cancelOrderList.get(0); 
 if (cancelOrder != null) { 
 //修改订单状态为取消 
 cancelOrder.setStatus(4); 
 orderMapper.updateByPrimaryKeySelective(cancelOrder); 
 OmsOrderItemExample orderItemExample = new OmsOrderItemExample(); 
 orderItemExample.createCriteria().andOrderIdEqualTo(orderId); 
 List<OmsOrderItem> orderItemList = orderItemMapper
		 .selectByExample(orderItemExample); 

		...
 } 
}

请求重试重复扣积分

原来下单之后会：
- 使用优惠券
- 扣积分
- 删除购物车商品
- 发送延迟取消消息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


orderItemDao.insertList(orderItemList); 
if (orderParam.getCouponId() != null) { 
 updateCouponStatus(orderParam.getCouponId(), currentMember.getId(), 1); 
} 
if (orderParam.getUseIntegration() != null) { 
 order.setUseIntegration(orderParam.getUseIntegration()); 
 if(currentMember.getIntegration()==null){ 
 currentMember.setIntegration(0); 
 } 
 memberService.updateIntegration(currentMember.getId(), 
		 currentMember.getIntegration() - orderParam.getUseIntegration()); 
} 
deleteCartItemList(cartPromotionItemList, currentMember); 
sendDelayMessageCancelOrder(order.getId());

如果重试请求拿到原订单后，继续执行这些代码，仍然可能重复扣积分。

支付通知来了，直接把订单改成已支付

原来验签后直接拿订单号调用支付成功逻辑，缺少完整付款记录和校验。
如果订单金额不对，用户付了0.01元但是支付通知签名是真的，就能用0.01买走该订单商品。
如果支付宝没收到success通知，就会一直发送同一条通知，trade_no是同一个，每次通知都会跑一边paySuccess()流程，修改订单支付状态、扣库存。
或者同一张订单付了两次钱，交易号不同，多交的一笔钱会直接返回success支付成功，不会退款。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


public Integer paySuccess(Long orderId, Integer payType) { 
 OmsOrder order = new OmsOrder(); 
 order.setId(orderId); 
 order.setStatus(1); 
 order.setPaymentTime(new Date()); 
 order.setPayType(payType); 
 orderMapper.updateByPrimaryKeySelective(order); 
 
 OmsOrderDetail orderDetail = portalOrderDao.getDetail(orderId); 
 int count = portalOrderDao.updateSkuStock(orderDetail.getOrderItemList()); 
 return count; 
}

public String notify(Map<String, String> params) { 
 String result = "failure"; 
 boolean signVerified = false; 
 try { 
 //调用SDK验证签名 
 signVerified = AlipaySignature.rsaCheckV1(params, 
		 alipayConfig.getAlipayPublicKey(), 
		 alipayConfig.getCharset(), 
		 alipayConfig.getSignType()); 
 } catch (AlipayApiException e) { 
 log.error("支付回调签名校验异常！",e); 
 e.printStackTrace(); 
 } 
 if (signVerified) { 
 String tradeStatus = params.get("trade_status"); 
 if("TRADE_SUCCESS".equals(tradeStatus)){ 
 result = "success"; 
 log.info("notify方法被调用了，tradeStatus:{}",tradeStatus); 
 String outTradeNo = params.get("out_trade_no"); 
 portalOrderService.paySuccessByOrderSn(outTradeNo,1); 
 }else{ 
 log.warn("订单未支付成功，trade_status:{}",tradeStatus); 
 } 
 } else { 
 log.warn("支付回调签名校验失败！"); 
 } 
 return result; 
}

订单关闭后收到付款，又被强行改回待发货

本地超时任务关闭了订单之后，支付成功通知到达，验签就又会调用paySuccess()，执行一系列流程，把订单状态改成1。

设计下单幂等请求

由于上文讲到的问题，需要给下单请求加个唯一标识，让请求能安全地重试。还需要用户 ID ，把用户 ID 和客户端生成的请求幂等 key 作为联合主键去重，可以防止越权下单。

唯一键就是并发锁：

A 先 insert 成功，事务还没提交
B 的 insert 撞上唯一索引，会阻塞等待 A 的结果
A 提交：B 收到 DuplicateKeyException，进 catch，lock 读到 A 的 SUCCESS 记录并直接返回
A 回滚：B 的 insert 成功，B 接着创建订单

幂等前提是相同请求得到相同结果。如果同一个 key 带了不同参数，这就不是重试了，不能直接返回旧的订单，要对关键内容摘要做哈希(定长、省空间)，重放比对一致就是正常重试请求。

除此之外，需要标记下单请求处理进度。如果先插入幂等记录抢占 key，再创建订单。这时并发重试的第二个请求会因主键冲突失败，它需要知道第一个请求进行到哪了(库存和下单、优惠券的事务拆开了)：

state	含义	重试时的处理
PROCESSING	第一个请求还在处理	返回"处理中"，让客户端稍后重试或轮询
SUCCESS	订单已创建	直接返回 `order_id`
UNKNOWN	暂时没有可见记录，可能未提交	按业务决定：返回失败，或允许重置后重试

流程

INSERT
成功
1. 首次请求创建订单
2. 主键冲突 SELECT 幂等请求表
  1. hash 不同拒绝
  2. SUCCESS 返回 order_id
  3. PROCESSING 返回处理中
创建订单

建表

1
2
3
4
5
6
7
8


CREATE TABLE oms_order_request (
 member_id BIGINT NOT NULL,
 idempotency_key VARCHAR(64) NOT NULL,
 request_hash CHAR(64) NOT NULL,
 order_id BIGINT,
 state VARCHAR(16) NOT NULL,
 PRIMARY KEY(member_id, idempotency_key)
) ENGINE=InnoDB;

代码实现

SQL 和 DAO

Tips

lock 用 FOR UPDATE 有死锁的风险，InnoDB 里 insert 撞唯一键失败后，会对冲突的索引记录加 S 锁，持有到事务结束。

如果有两个以上的重复请求，各自持有 S 锁，都执行 SELECT ... FOR UPDATE ，把 S 升级成 X 两边互相等待对方释放 S 锁，其中一个被回滚。

重复请求只需要读最新数据，用共享锁读取即可，改成 FOR SHARE 。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64


...
public interface OrderRequestDao {

 @Insert("""
 INSERT INTO oms_order_request (
 member_id, idempotency_key, request_hash, state
 ) VALUES (
 #{memberId}, #{key}, #{hash}, 'PROCESSING'
 )
 """)
 int insert(@Param("memberId") Long memberId,
 @Param("key") String key,
 @Param("hash") String hash);

 @Select("""
 SELECT member_id AS memberId,
 idempotency_key AS idempotencyKey,
 request_hash AS requestHash,
 order_id AS orderId,
 state
 FROM oms_order_request
 WHERE member_id = #{memberId}
 AND idempotency_key = #{key}
 """)
 Row find(@Param("memberId") Long memberId,
 @Param("key") String key);

 @Select("""
 SELECT member_id AS memberId,
 idempotency_key AS idempotencyKey,
 request_hash AS requestHash,
 order_id AS orderId,
 state
 FROM oms_order_request
 WHERE member_id = #{memberId}
 AND idempotency_key = #{key}
 FOR SHARE
 """)
 Row lock(@Param("memberId") Long memberId,
 @Param("key") String key);

 @Update("""
 UPDATE oms_order_request
 SET order_id = #{orderId}, state = 'SUCCESS'
 WHERE member_id = #{memberId}
 AND idempotency_key = #{key}
 AND request_hash = #{hash}
 AND state = 'PROCESSING'
 AND order_id IS NULL
 """)
 int complete(@Param("memberId") Long memberId,
 @Param("key") String key,
 @Param("hash") String hash,
 @Param("orderId") Long orderId);

 @Data
 class Row {
 private Long memberId;
 private String idempotencyKey;
 private String requestHash;
 private Long orderId;
 private String state;
 }
}

业务代码

并发请求可能等待唯一键锁。锁等待超时的处理放在后面的 Controller 中，不能在事务已经失败后继续写订单。

幂等记录要和订单必须同生共死，失败时要整体回滚。如果不是：

记录提交，订单失败，客户端用原 key 重试一直卡在PROCESSING。
订单提交，记录失败，重试查不到记录，重复下单和没有幂等记录表一样。

放进同一个事务后，订单创建失败，幂等记录一起回滚，MySQL 里什么都没留下。probe 返回 UNKNOWN，客户端可以放心用原 key 重新下单。

部分下单服务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114


@Transactional(readOnly = true)
public OrderCreateParam probe(OrderRequestIdentity identity) {
	validateIdentity(identity);

	String hash = hash(identity);
	OrderRequestDao.Row row = requestDao.find(
			identity.memberId(), identity.idempotencyKey());

	return toResult(identity, hash, row);
}

@Transactional(rollbackFor = Exception.class)
public OrderCreateParam create(OrderCreateParam param) {
	if (param == null) {
		throw badRequest("下单参数不能为空");
	}

	OrderRequestIdentity identity = param.getIdentity();
	validateIdentity(identity);
	String hash = hash(identity);

	try {
		requestDao.insert(
				identity.memberId(),
				identity.idempotencyKey(),
				hash);
	} catch (DuplicateKeyException ex) {
		// 同会员、同 key 已存在。
		// 如果另一笔事务尚未提交，唯一键检查会等待其结果。
		OrderRequestDao.Row row = requestDao.lock(
				identity.memberId(), identity.idempotencyKey());

		if (row == null) {
			throw new IllegalStateException("幂等请求记录不存在");
		}
		return toResult(identity, hash, row);
	}

	// 以下分支只有首次插入请求记录的事务能够执行。
	OmsOrder order = param.getOrder();
	if (order == null
			|| !Objects.equals(order.getMemberId(), identity.memberId())
			|| order.getId() != null
			|| param.getOrderItemList() == null
			|| param.getOrderItemList().isEmpty()) {
		throw badRequest("订单或订单明细不合法");
	}

	// 创建状态由订单服务决定。
	order.setStatus(0);
	order.setDeleteStatus(0);
	order.setPaymentTime(null);

	// 调用另一个 Spring Bean，原 create() 的事务会加入当前事务。
	OrderCreateParam result = orderService.create(param);

	int changed = requestDao.complete(
			identity.memberId(),
			identity.idempotencyKey(),
			hash,
			result.getOrder().getId());

	if (changed != 1) {
		throw new IllegalStateException("幂等请求完成状态写入失败");
	}

	result.setIdentity(identity);
	result.setRequestState("SUCCESS");
	result.setCreated(true);
	return result;
}

private OrderCreateParam toResult(
		OrderRequestIdentity identity,
		String hash,
		OrderRequestDao.Row row) {

	OrderCreateParam result = new OrderCreateParam();
	result.setIdentity(identity);
	result.setCreated(false);
	result.setOrderItemList(List.of());

	if (row == null) {
		// 普通查询看不到未提交记录，不能断言请求从未发生。
		result.setRequestState("UNKNOWN");
		return result;
	}

	if (!hash.equals(row.getRequestHash())) {
		throw new ResponseStatusException(
				HttpStatus.CONFLICT,
				"同一个幂等键不能用于不同的下单参数");
	}

	if ("PROCESSING".equals(row.getState())) {
		result.setRequestState("PROCESSING");
		return result;
	}

	if (!"SUCCESS".equals(row.getState())
			|| row.getOrderId() == null) {
		throw new IllegalStateException("幂等请求状态异常");
	}

	OmsOrder order = orderService.getById(row.getOrderId());
	if (order == null) {
		throw new IllegalStateException("幂等记录对应的订单不存在");
	}

	result.setRequestState("SUCCESS");
	result.setOrder(order);
	result.setOrderItemList(orderService.getItems(order.getId()));
	return result;
}

Controller

不能在 Service 的 @Transcational 方法内部 catch 掉这个异常，Spring 看不到异常，会以为方法成功，尝试 commit，死锁时数据不一致可能已经回滚了，状态不一致了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


public OrderCreateParam create(OrderCreateParam param) {
 try {
 return requestService.create(param);
 } catch (CannotAcquireLockException ex) {
 // 进入这里时，requestService 的事务已经回滚。
 // 让客户端查询并使用原 key 重试。
 OrderCreateParam result = new OrderCreateParam();
 result.setIdentity(param.getIdentity());
 result.setRequestState("PROCESSING");
 result.setCreated(false);
 result.setOrderItemList(java.util.List.of());
 return result;
 }
}

门户服务里下单逻辑取消订单等逻辑都要修改。

长事务的缺点

锁持有时间变长。行锁需要到事务提交/回滚后才释放，需要修改只能排队，容易出现锁等待超时。所以要在 Controller 捕获 CannotAcquireLockException。
占数据库连接。容易堵住数据库连接，其他接口也拿不到连接，整个服务都慢。
死锁概率上升。
回滚耗时。

可以把幂等记录作为一个短事务先提交成 PROCESSING，订单走自己的事务，最后更新记录。但是，处理卡死在 PROCESSING 恢复的复杂度非常大(加个时间字段、CAS、定时任务)，~~我偷个懒先~~。

支付幂等

建表

核心思路就是把一笔真实的付款单独存成一条流水，用交易号唯一性保证同一笔钱只入账一次。

交易号在同一个渠道唯一，把 provider 和 trade_no 作为主键幂等判断。这样同一笔付款重复通知会抛异常，两条相同通知后一个 INSERT 阻塞等前一个事务结果，和订单幂等处理相似。

订单表维护三个状态：

状态	含义	什么时候出现
`RECEIVED`	已收到付款信息，事务内处理中	先插入这条记录，占住唯一键
`APPLIED`	已用于支付该订单	订单状态更新成功后，同一事务内改成这个
`REFUND_PENDING`	已收款，需要退款	订单已被另一笔付款支付、订单已关闭等，这笔钱无法履约

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


CREATE TABLE oms_order_payment (
 provider VARCHAR(16)
 CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
 trade_no VARCHAR(128)
 CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
 order_id BIGINT NOT NULL,
 amount DECIMAL(18, 2) NOT NULL,
 state VARCHAR(32) NOT NULL,
 create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
 PRIMARY KEY (provider, trade_no),
 KEY idx_order_id (order_id)
) ENGINE=InnoDB;

代码实现

notify 通知接收

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74


public String notify(Map<String, String> params) {
 try {
 boolean verified = AlipaySignature.rsaCheckV1(
	 params,
 alipayConfig.getAlipayPublicKey(),
 alipayConfig.getCharset(),
 alipayConfig.getSignType());

 if (!verified) {
 return "failure";
 }

 if (!Objects.equals(alipayConfig.getAppId(), params.get("app_id"))) {
 return "failure";
 }

 if (alipayConfig.getSellerId() == null
 || !Objects.equals(
 alipayConfig.getSellerId(),
 params.get("seller_id"))) {
 return "failure";
 }

 String tradeStatus = params.get("trade_status");

 if (!"TRADE_SUCCESS".equals(tradeStatus)
 && !"TRADE_FINISHED".equals(tradeStatus)) {
 // 非付款成功通知，不执行支付状态转换。
 return "success";
 }

 PaymentNotice notice = new PaymentNotice(
 params.get("out_trade_no"),
 params.get("trade_no"),
 new BigDecimal(params.get("total_amount")));

 OrderTransitionResult result = orderService.acceptAlipay(notice);

 if ("REFUND_PENDING".equals(result.result())) {
 // 订单服务已持久化待退款记录。
 // 后续退款流程处理，不能确认库存或强行改订单状态。
 log.warn(
 "付款已登记待退款，orderId:{}, tradeNo:{}",
 result.order().getId(),
 notice.tradeNo());

 return "success";
 }

 if ("PAID".equals(result.result())
 || "ALREADY_PAID".equals(result.result())) {

 Integer status = result.order().getStatus();
 if (Integer.valueOf(1).equals(status)
 || Integer.valueOf(2).equals(status)
 || Integer.valueOf(3).equals(status)) {

 Long orderId = result.order().getId();
 
 // 相同 reservationId 的重复确认必须幂等。
 // 如果上次状态已提交但确认库存失败，
 // 平台重试通知时仍可重试这里。
 inventoryService.confirm(
 SkuStockReserveParam.reservationIdForOrder(orderId),
 new SkuStockReserveParam.ReservationActionRequest(orderId));
 }
 return "success";
 }
 return "failure";
 } catch (Exception ex) {
 log.error("处理支付宝支付通知失败", ex);
 return "failure";
 }
}

订单校验

主要流程：

校验参数
锁订单行 (FOR UPDATE)，同一订单的两条通知会在这里排队，关闭订单也会锁订单行。
插入付款记录
锁付款记录，核对订单和金额，确认这个交易号对应的是不是同一订单、同一金额。
付款金额不对退款
看付款记录状态
- APPLIED：这笔钱以前已经用于支付订单，当前通知是重发，返回 ALREADY_PAID
- REFUND_PENDING：这笔钱以前已经被判定要退款，重发时返回同样的结果
- RECEIVED：刚插入的新记录，继续处理
条件更新订单，如果失败(关闭，或者被另一笔付款支付)不覆盖已有订单状态。

Tips

为什么先锁 oms_order 再操作 oms_order_payment ？

如果反过来，一旦有其他地方按订单查流水加锁，加锁顺序相反就会引发死锁。需要固定顺序，先订单后流水的加锁顺序防止死锁。

场景	acceptAlipay	notify
订单待付款，首次通知	`PAID`	确认库存，返回 success
同一交易号重发，已经入账	`ALREADY_PAID`	再确认一次库存（补偿），success
订单已关闭，或已被另一笔付款支付	`REFUND_PENDING`	打日志，success
同一交易号重发，之前已是待退款	`REFUND_PENDING`	打日志，success
订单金额不符	`REFUND_PENDING`	打日志，success
参数非法、订单不存在、交易号冲突	抛异常，整个事务回滚	catch 后返回 failure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


@Transactional(rollbackFor = Exception.class) 
public OrderTransitionResult acceptAlipay(PaymentNotice notice) { 
 if (notice == null 
 || !StringUtils.hasText(notice.orderSn()) 
 || !StringUtils.hasText(notice.tradeNo()) 
 || notice.tradeNo().length() > 128 
 || notice.amount() == null 
 || notice.amount().signum() <= 0 
 || notice.amount().stripTrailingZeros().scale() > 2) { 
 throw error(HttpStatus.BAD_REQUEST, "付款参数不合法"); 
 } 
 
 OmsOrder order = stateDao.lockByOrderSn(notice.orderSn()); 
 if (order == null) { 
 throw error(HttpStatus.NOT_FOUND, "订单不存在"); 
 } 
 
 try { 
 paymentDao.insert(notice.tradeNo(), order.getId(), notice.amount()); 
 } catch (DuplicateKeyException ex) { 
 // 重复通知仍需读取已有付款记录，核对订单、金额和处理状态。 
 } 
 
 OrderPaymentDao.Row payment = paymentDao.lock(notice.tradeNo()); 
 if (payment == null) { 
 throw new IllegalStateException("付款记录不存在"); 
 } 
 
 if (!Objects.equals(payment.getOrderId(), order.getId()) 
 || payment.getAmount().compareTo(notice.amount()) != 0) { 
 throw error(HttpStatus.CONFLICT, "该平台交易号已经绑定其他订单或金额"); 
 } 
 
 if ("APPLIED".equals(payment.getState())) { 
 return new OrderTransitionResult("ALREADY_PAID", order); 
 } 
 if ("REFUND_PENDING".equals(payment.getState())) { 
 return new OrderTransitionResult("REFUND_PENDING", order); 
 } 
 if (!"RECEIVED".equals(payment.getState())) { 
 throw new IllegalStateException("付款记录状态异常"); 
 } 
 
 if (order.getPayAmount() == null 
		 || order.getPayAmount().compareTo(notice.amount()) != 0) { 
 finishPayment(notice.tradeNo(), "REFUND_PENDING"); 
 return new OrderTransitionResult("REFUND_PENDING", order); 
 } 
 
 int changed = stateDao.markPaid(order.getId()); 
 if (changed == 1) { 
 finishPayment(notice.tradeNo(), "APPLIED"); 
 return new OrderTransitionResult("PAID", stateDao.lockById(order.getId())); 
 } 
 
 finishPayment(notice.tradeNo(), "REFUND_PENDING"); 
 return new OrderTransitionResult("REFUND_PENDING", 
		 stateDao.lockById(order.getId())); 
}

其它

跨服务最终一致性尚未完成。订单状态已提交后，确认或释放库存仍可能失败。返回失败让平台重试只能提供一条恢复路径，不能代替可靠事件和恢复任务。
积分、优惠券等外围操作仍存在中断窗口。例如订单创建提交后，门户还没扣积分就宕机，重试虽然不会重复下单，却也不会自动补做缺失操作，需要后续事件机制处理。

原单体项目主要只考虑了正常流程，但一旦把订单服务独立拆出来，网络超时重试、并发读写、回调乱序就会出现很多问题。幂等和状态机看似多写了不少防御性代码和冗余表，但在交易链路里，保证可靠性，永远比省事更重要。

并发下库存预占与扣减的问题

Fri, 11 Sep 2026 17:28:50 +0000

我翻了翻这个商城项目的库存代码，想把它改造成分布式微服务架构。

在分布式场景下，网络请求不能认为是可靠的，这包括请求超时，重复投递，消息乱序等等情况。这个项目的库存扣减防超卖并不是原子的，只维护一个lock_stock，无法解决库存预占幂等问题，库存属于哪个订单，取消请求应该释放哪一批库存。

原项目的问题

当前的锁库存是这么做的： lock_stock +quantity，SQL 没有判断剩余的库存，Service 若把 Mapper 的影响行数直接当成“预占成功”，这个返回值只能证明某一行被更新，不能证明库存充足，这非常容易超卖。无论 stock - lock_stock 是否足够，只要 SKU 存在，更新都可能成功。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


<update id="updateByPrimaryKeySelective" parameterType="com.macro.mall.model.PmsSkuStock"> 
 update pms_sku_stock 
 <set> 
 <if test="productId != null"> 
 product_id = #{productId,jdbcType=BIGINT}, 
 </if> 
 <if test="skuCode != null"> 
 sku_code = #{skuCode,jdbcType=VARCHAR}, 
 </if> 
 <if test="price != null"> 
 price = #{price,jdbcType=DECIMAL}, 
 </if> 
 <if test="stock != null"> 
 stock = #{stock,jdbcType=INTEGER}, 
 </if> 
 <if test="lowStock != null"> 
 low_stock = #{lowStock,jdbcType=INTEGER}, 
 </if> 
 <if test="pic != null"> 
 pic = #{pic,jdbcType=VARCHAR}, 
 </if> 
 <if test="sale != null"> 
 sale = #{sale,jdbcType=INTEGER}, 
 </if> 
 <if test="promotionPrice != null"> 
 promotion_price = #{promotionPrice,jdbcType=DECIMAL}, 
 </if> 
 <if test="lockStock != null"> 
 lock_stock = #{lockStock,jdbcType=INTEGER}, 
 </if> 
 <if test="spData != null"> 
 sp_data = #{spData,jdbcType=VARCHAR}, 
 </if> 
 </set> 
 where id = #{id,jdbcType=BIGINT} 
</update>

锁库存的时候并不能解决并发问题。整个 Java 方法不会自动变成数据库原子操作。假设 stock = 1、lock_stock = 0，请求 A 和 B 都可能读到 0，并分别把 1 写回数据库。数据库里最终甚至可能仍是 lock_stock = 1，但两个订单都收到了成功结果。这是一次丢失更新，库存数字已经无法反映真实的业务归属。如果改成没有条件的 lock_stock = lock_stock + 1，结果又会变成 lock_stock = 2，同样超过总库存。

1
2
3
4
5
6
7
8


private void lockStock(List<CartPromotionItem> cartPromotionItemList) { 
 for (CartPromotionItem cartPromotionItem : cartPromotionItemList) { 
 PmsSkuStock skuStock = skuStockMapper.selectByPrimaryKey(cartPromotionItem.getProductSkuId()); 
 skuStock.setLockStock(skuStock.getLockStock() + cartPromotionItem.getQuantity());
 // 如果这时候库存没了，还会继续预扣 
 skuStockMapper.updateByPrimaryKeySelective(skuStock); 
 } 
}

1
2
3
4


<sql id="Base_Column_List"> 
 id, product_id, sku_code, price, stock, low_stock, pic, sale, promotion_price, lock_stock, 
 sp_data 
</sql>

1

select <include refid="Base_Column_List" /> from pms_sku_stock where id = #{id,jdbcType=BIGINT}

没有预占流水记录，只有一个锁定库存数量字段。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


CREATE TABLE `pms_sku_stock` (
 `id` bigint NOT NULL AUTO_INCREMENT,
 `product_id` bigint DEFAULT NULL,
 `sku_code` varchar(64) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT 'sku编码',
 `price` decimal(10,2) DEFAULT NULL,
 `stock` int DEFAULT '0' COMMENT '库存',
 `low_stock` int DEFAULT NULL COMMENT '预警库存',
 `pic` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '展示图片',
 `sale` int DEFAULT NULL COMMENT '销量',
 `promotion_price` decimal(10,2) DEFAULT NULL COMMENT '单品促销价格',
 `lock_stock` int DEFAULT '0' COMMENT '锁定库存',
 `sp_data` varchar(500) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '商品销售属性，json格式',
 PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=243 DEFAULT CHARSET=utf8mb3 ROW_FORMAT=DYNAMIC COMMENT='sku的库存';

订单A取消时，只知道要释放两件，但无法确认这两件是否属于订单A，这也会带来幂等问题，订单A的取消请求发了两次，就会增加四件，虚增库存。这也导致无法审计，难以实现超时释放库存。

为什么要预占库存

订单业务流程是先下单，再支付/取消，库存会发生变化。如果下单时直接扣库存，取消订单恢复库存的时候不知道扣了多少库存，增加一个预扣字段，就能解决，方便了订单状态管理，这就是预占库存。而且，下单和支付不是一个瞬时事务。如果不预占，用户下单后库存可能被其他人抢走。

但是，预占库存会带来一些问题：在秒杀或热门商品场景下，用户下单而不支付，会让很多库存锁定，正常买家无法正常下单。如果扣库存成功，订单服务挂了，可能出现库存减少但是没有订单的情况。

库存原子更新

这个项目目前是单体项目，一条SQL语句的执行是原子的，所以用条件更新即可防止超卖。

1
2


UPDATE ims_sku_stock SET lock_stock = lock_stock + #{quantity} 
WHERE sku_id = #{skuId} AND stock - lock_stock &gt;= #{quantity}

InnoDB 执行这条 UPDATE 时会对目标库存行加排他锁。并发请求会在这一行上串行，后到的请求会基于更新后的值再次判断条件。因此，“判断库存够不够”和“增加锁定数量”不会被其他事务插入，这一条SQL是原子的。

但是这原子更新就意味着有行锁，秒杀情况下会有大量请求竞争同一行的行锁，库存扣减与数据库交互，性能会受到数据库连接数，IO，锁等等的性能限制。

这条 SQL 解决了超卖，却没有解决幂等。相同请求执行两次，仍会把 lock_stock 增加两次。要识别相同请求，库存预占必须有业务身份。

库存预占幂等

幂等就是同一个业务执行很多次，但是业务效果和执行一次相同。前端的防连点更不能替代服务端幂等设计。

原项目有三个库存量：

stock：当前库存总量；
lock_stock：已预占、尚未确认成交的数量；
stock - lock_stock：当前可售数量。

下单时只增加 lock_stock。支付成功后，同时减少 stock 和 lock_stock；订单取消时只减少 lock_stock。已经确认成交后的退款或退货属于另一条入库流程，不能再调用预占释放接口。

只增加一个 lock_stock 字段仍然不够。它只能表示锁了多少库存，不知道是哪个订单锁的。因此需要一张预占单记录请求和状态，再用预占明细记录每个 SKU 的数量：

还需要设置一个过期字段，再加上扫描主动过期，防止库存被无限占用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


CREATE TABLE ims_reservation (
 reservation_id VARCHAR(64) PRIMARY KEY,
 order_id BIGINT NOT NULL,
 request_hash CHAR(64),
 state VARCHAR(16) NOT NULL,
 expires_at DATETIME(3) NULL COMMENT '预占过期时间',
 created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
 updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
 UNIQUE KEY uk_reservation_order(order_id)
) ENGINE=InnoDB;

CREATE TABLE ims_reservation_item (
 reservation_id VARCHAR(64) NOT NULL,
 sku_id BIGINT NOT NULL,
 quantity INT NOT NULL,
 PRIMARY KEY(reservation_id, sku_id)
) ENGINE=InnoDB;

reservation_id 由订单服务生成。同一个业务请求重试时必须继续使用原 ID，不能每次重试都生成新值。order_id 上的唯一索引进一步限制一个订单只能对应一张预占单。

request_hash 是发现幂等键被误用。服务先合并重复 SKU、按 sku_id 排序，再对订单号和明细计算 SHA-256。同一个 reservation_id 如果带着不同商品或数量再次请求，服务会返回参数冲突，而不是把它当成正常重试。

两张预占表属于同一个库存库时可以加外键，但在分库、归档或高并发写入场景中，外键也会增加迁移和写入约束。

库存预占与释放

预占单有状态迁移：

操作	允许的当前状态	结果	库存变化
`reserve`	`INIT`	`RESERVED`	`lock_stock += quantity`
重复 `reserve`	`RESERVED`	返回 `RESERVED`	无
`confirm`	`RESERVED`	`CONFIRMED`	`stock -= quantity`，`lock_stock -= quantity`
重复 `confirm`	`CONFIRMED`	返回 `CONFIRMED`	无
`release`	`RESERVED`	`RELEASED`	`lock_stock -= quantity`
重复 `release`	`RELEASED`	返回 `RELEASED`	无
`INIT` 是事务内部的中间状态。正常情况下，事务提交后外部只能看到 `RESERVED`；任一 SKU 库存不足时，整个事务回滚，已经增加的其他 SKU 锁定量和预占明细也会一起撤销。

confirm 和 release 都先执行：

1
2
3
4


SELECT order_id, request_hash, state
FROM ims_reservation
WHERE reservation_id = ?
FOR UPDATE;

FOR UPDATE把同一张预占单上的一行加悲观锁。支付确认和取消同时到达时，只有先拿到行锁的一方能完成终态迁移，另一方会看到新的状态并停止修改库存。

当支付和超时释放请求同时到达，如果业务要求按支付发生时间裁决，就要引入支付时间或订单状态作为额外依据，不能只依赖任务执行先后。

超时库存释放

预占成功时写入 expires_at，后端定时任务扫描：

1
2
3
4
5
6


SELECT reservation_id, order_id
FROM ims_reservation
WHERE state = 'RESERVED'
 AND expires_at <= NOW(3)
ORDER BY expires_at
LIMIT 100;

任务要逐条调用同一个 release 方法。这样人工取消、订单超时和任务重试共用一套幂等逻辑。多个库存服务实例可能同时扫到同一张预占单，但 SELECT ... FOR UPDATE 会将释放串行化，后到的实例只会读到 RELEASED。

定时任务需要从另一个 Spring Bean 调用 ReservationService.release，让调用经过 Spring 事务代理；不要在同一个类里用 this.release(...) 自调用。项目还需要启用 @EnableScheduling。

扫描任务解决的是库存服务内部的兜底释放。订单服务仍应在订单取消或支付超时时主动发送释放命令，定时扫描只负责处理漏发、延迟和服务故障留下的预占。

扫描时间要根据支付时限和数据库负载调整。

代码示例

预占库存

INSERT ... ON DUPLICATE KEY UPDATE 让重复请求失败，随后再锁定并检查已存在的预占单。多 SKU 请求使用 TreeMap 按 sku_id 排序，让不同事务尽量以相同顺序锁库存行，从而降低死锁概率。死锁仍可能由其他更新路径引入，生产环境还需要对数据库死锁异常做有限次数重试。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


@Transactional
public String reserve(String reservationId, long orderId, List<Line> lines) {
 validateIdentity(reservationId, orderId);
 Map<Long, Integer> quantities = normalize(lines);
 String hash = fingerprint(orderId, quantities);

 jdbc.update("""
 INSERT INTO ims_reservation(
 reservation_id, order_id, request_hash, state, expires_at
 )
 VALUES (?, ?, ?, 'INIT', TIMESTAMPADD(SECOND, ?, NOW(3)))
 ON DUPLICATE KEY UPDATE reservation_id = reservation_id
 """, reservationId, orderId, hash, reservationTtlSeconds);

 Header header = lockedHeader(reservationId, orderId);
 if ("RELEASED".equals(header.state())) {
 throw new ReservationStateException("RESERVATION_ALREADY_RELEASED");
 }
 if (!hash.equals(header.hash())) {
 throw new IllegalArgumentException("IDEMPOTENCY_PARAMETER_CONFLICT");
 }
 if (!"INIT".equals(header.state())) {
 return header.state();
 }

 for (Map.Entry<Long, Integer> entry : quantities.entrySet()) {
 int quantity = entry.getValue();
 int updated = jdbc.update("""
 UPDATE pms_sku_stock
 SET lock_stock = lock_stock + ?
 WHERE id = ? AND stock - lock_stock >= ?
 """, quantity, entry.getKey(), quantity);
 if (updated != 1) {
 throw new StockUnavailableException(entry.getKey());
 }

 jdbc.update("""
 INSERT INTO ims_reservation_item(reservation_id, sku_id, quantity)
 VALUES (?, ?, ?)
 """, reservationId, entry.getKey(), quantity);
 }

 jdbc.update("""
 UPDATE ims_reservation
 SET state = 'RESERVED', updated_at = NOW(3)
 WHERE reservation_id = ? AND state = 'INIT'
 """, reservationId);
 return "RESERVED";
}

支付后确认

确认时同时减少 stock 和 lock_stock。例如确认前 stock = 10、lock_stock = 2，可售库存是 8；确认两件后变为 stock = 8、lock_stock = 0，可售库存仍是 8。支付只是把两件商品从RESERVED转成CONFIRMED，不会再次占用可售库存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


@Transactional
public String confirm(String reservationId, long orderId) {
 Header header = lockedHeader(reservationId, orderId);
 if ("CONFIRMED".equals(header.state())) {
 return "CONFIRMED";
 }
 if (!"RESERVED".equals(header.state())) {
 throw new ReservationStateException("RESERVATION_NOT_RESERVED");
 }

 for (Line line : items(reservationId)) {
 int updated = jdbc.update("""
 UPDATE pms_sku_stock
 SET stock = stock - ?, lock_stock = lock_stock - ?
 WHERE id = ? AND stock >= ? AND lock_stock >= ?
 """, line.quantity(), line.quantity(), line.skuId(),
 line.quantity(), line.quantity());
 if (updated != 1) {
 throw new IllegalStateException("INVENTORY_INVARIANT_BROKEN");
 }
 }

 jdbc.update("""
 UPDATE ims_reservation
 SET state = 'CONFIRMED', updated_at = NOW(3)
 WHERE reservation_id = ? AND state = 'RESERVED'
 """, reservationId);
 return "CONFIRMED";
}

取消后释放

释放数量来自 ims_reservation_item，而不是取消请求传入的数量。客户端因此无法多释放库存，同一取消请求重复执行也不会再次减少 lock_stock。

方法开头插入 RELEASED 还有一个用途：处理消息乱序。如果取消消息先到、预占消息后到，取消请求会先写入一张没有明细的 RELEASED 记录。迟到的 reserve 看到该状态后直接拒绝，不会在订单已经取消后重新锁库存。

这段逻辑只处理取消和预占之间的乱序。confirm 早于 reserve 时会被拒绝，因为没有预占明细可供确认。订单服务应在确认预占成功后才允许进入支付流程，并让同一 reservation_id 的命令按顺序投递。如果消息通道不能保证顺序，确认命令需要在预占完成后重试，不能跳过状态检查直接扣库存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


@Transactional
public String release(String reservationId, long orderId) {
 jdbc.update("""
 INSERT INTO ims_reservation(
 reservation_id, order_id, request_hash, state, expires_at
 )
 VALUES (?, ?, NULL, 'RELEASED', NULL)
 ON DUPLICATE KEY UPDATE reservation_id = reservation_id
 """, reservationId, orderId);

 Header header = lockedHeader(reservationId, orderId);
 if ("RELEASED".equals(header.state())) {
 return "RELEASED";
 }
 if (!"RESERVED".equals(header.state())) {
 throw new ReservationStateException("RESERVATION_CANNOT_RELEASE");
 }

 for (Line line : items(reservationId)) {
 int updated = jdbc.update("""
 UPDATE pms_sku_stock
 SET lock_stock = lock_stock - ?
 WHERE id = ? AND lock_stock >= ?
 """, line.quantity(), line.skuId(), line.quantity());
 if (updated != 1) {
 throw new IllegalStateException("INVENTORY_INVARIANT_BROKEN");
 }
 }

 jdbc.update("""
 UPDATE ims_reservation
 SET state = 'RELEASED', updated_at = NOW(3)
 WHERE reservation_id = ? AND state = 'RESERVED'
 """, reservationId);
 return "RELEASED";
}

超时库存释放

示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public List<ExpiredReservation> findExpired(int limit) {
	if (limit <= 0 || limit > 1000) {
		throw new IllegalArgumentException("INVALID_BATCH_SIZE");
	}
	return jdbc.query("""
			SELECT reservation_id, order_id
			FROM ims_reservation
			WHERE state = 'RESERVED' AND expires_at <= NOW(3)
			ORDER BY expires_at
			LIMIT ?
			""", (rs, rowNum) -> new ExpiredReservation(
			rs.getString("reservation_id"), rs.getLong("order_id")), limit);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


@Component
public class ReservationExpiryJob {
 private static final Logger LOGGER = LoggerFactory.getLogger(ReservationExpiryJob.class);

 private final ReservationService reservationService;
 private final int batchSize;

 public ReservationExpiryJob(
 ReservationService reservationService,
 @Value("${inventory.reservation-expiry-batch-size:100}") int batchSize) {
 this.reservationService = reservationService;
 this.batchSize = batchSize;
 }

 @Scheduled(fixedDelayString = "${inventory.reservation-expiry-scan-ms:5000}")
 public void releaseExpiredReservations() {
 for (ExpiredReservation reservation : reservationService.findExpired(batchSize)) {
 try {
 // release 通过 Spring 代理进入独立事务，多实例重复扫描也不会重复释放。
 reservationService.release(
 reservation.reservationId(), reservation.orderId());
 } catch (IllegalStateException ex) {
 // 支付确认可能与超时释放同时发生，最终状态由预占单行锁串行决定。
 LOGGER.info("Skip expired reservation {}, reason={}",
 reservation.reservationId(), ex.getMessage());
 } catch (RuntimeException ex) {
 LOGGER.warn("Failed to release expired reservation {}",
 reservation.reservationId(), ex);
 }
 }
 }
}

超时重试可靠性

微服务调用会出现响应超时，调用方如果没收到成功信息，不知道库存服务有没有提交事务。

有了幂等设计，也就是reservation_id，订单服务可以直接重试。

第一次请求没提交，重试正常预占
第一次已经提交没收到成功消息，重试发现RESERVED，直接返回当前状态
同一个 ID 被错误用到另一组商品，request_hash不一致返回冲突
订单已经取消，重试读到RELEASED，不会重新预占

确认和释放逻辑相同，调用方如果超时，继续用reservation_id重试，库存变化最多发生一次。

没有解决分布式事务

@Transactional 只覆盖库存服务自己的数据库，不能同时回滚订单库。以下故障仍然可能发生：

库存预占成功，订单服务在记录结果前挂了
订单取消成功，释放请求没有发出去
支付成功，确认库存的消息重复或延迟到达

一种常见做法是让订单服务在本地事务中同时写订单和 outbox 事件，再由后台任务可靠投递。库存服务按至少一次语义消费命令，并依靠 reservation_id 去重。库存服务处理完成后也可以用 outbox 发布预占结果，订单服务再幂等更新订单状态。

如果仍使用同步 HTTP，原则也不变：订单先落库，再调用库存；遇到超时就使用相同幂等键重试。预占成功但订单流程没有继续时，由主动补偿和 expires_at 兜底释放。

只有在调用方可靠地驱动状态变化、失败命令可以持续重试时，完整业务流程才真正闭环。库存库里的一个本地事务不能代替跨服务一致性方案。

行锁性能瓶颈

条件更新保证了正确性，也意味着热门 SKU 的请求会竞争同一行锁。数据库连接数、事务耗时、磁盘 IO 和锁等待都会限制吞吐量。这个问题不能靠优化 SQL 来消除。

不同的业务可以采用不同的方案。

普通商品场景通常先采用数据库条件更新，因为实现简单、数据源单一，也容易核对。秒杀场景可以考虑请求排队、Redis Lua 原子预扣、库存分段或令牌化，但这些方案会引入缓存和数据库之间的一致性、补偿及对账问题。优化前应先压测确认瓶颈，不能用一套尚未闭环的双写方案替换已经正确的数据库事务。

无论是否引入缓存，预占身份、状态机和幂等语义仍然需要保留。Redis 可以改变竞争发生的位置，不能替代“这批库存属于哪个订单”的业务记录。

先把数据库的库存，预占对账做得可靠，后续的消息可靠投递，缓存预扣和秒杀优化才有可核对和补偿的基础。