脑补了一个微服务场景, 请问解决方案是什么?

[chaleaochexist]

还是说没有解决方案

卖苹果, 库存 3 个. 有人买了, 先减库存(苹果-1)因为支付失败,需要逆操作补库存(苹果+1).

但是苹果+1 在先 -1 在后. 理论上某个时刻苹果的库存变成 4 了.

请问如何解决?

[hhjswf]

为什么+1 会在先？
要是说某个时刻库存是 2 ，人间蒸发了 1 个，怎么保证强一致性，那还有的讨论

[potatowish]

苹果-1 发了一条消息，苹果+1 又发了一条消息，消息在投递和消费的过程如果不能保证顺序性就可能出现你说的这种问题。

[jdOY]

1.幂等
2.先扣减再补
3.补库后的总数小于等于原始的总数

[ltkun]

i++和++i

[lsk569937453]

这就是分布式事务啊。。。。。。

[chunworkhard]

学习学习~

[asssfsdfw]

减库存的时候发两个时间，一个用来减库存，一个用来补库存。 补库存的时间晚于减库存的时间。

[asssfsdfw]

打错了， 是购买的时候发两个时间

[asssfsdfw]

也可以不发时间，打两个标记。 补库存的时候发现减库存的标记还在，那就清除两个标记，不增不减。

[JYii]

好像没问题啊。下订单，库存-1 ，生成交易单。交易失败（立即或一段时间后自动失败），库存+1 。

[bthulu]

支付失败是不补库存的, 要客户取消订单才补库存.

[li746224]

实际场景中前台销售库存 不等于 仓库库存，即使真出现销售库存变多了，问题也不大的

[realpg]

关系数据库就事务行锁锁住就完了

非关系数据库，就自己实现个事务锁机制

[b1t]

支付失败有必要扣库存么

[hyqCrystal]

根据业务场景 要发生加一的场景一定是支付失败后库存+1 ，此时前面业务一定发生了商品减库存这个业务。那么业务上再做+1 的时候可以强制校验前面业务是否成功。可以使用操作时间，也可以使用最终一致性的消息表来都行。

[summerLast]

增加一个锁定状态，出库在扣减库存

[justfindu]

消息队列?

[realpg]

抱歉我傻逼了 没注意你说微服务隐含的意思

这就类似金融场景要求强一致的，不 confirm 你就敢回馈给用户结果？

就好像，银行转账，UI 系统把 operation 发给后台，不等执行结果就告诉用户你转账成功钱没了?


正确的方法，第一个生成订单扣库存，你发 message 到 mq ，这时候并不能给用户订单生成，要等待这个确实后端处理完了库存扣减完毕，这个反馈操作成功了，才能真生成订单。

而你没生成订单，就没有能取消订单，恢复库存的操作。

[tabris17]

@realpg 难怪我根本看不懂楼主在说啥。搞了半天他的意思是发了一条异步消息就直接生成订单了，也不管消息有没有被处理成功

[hoopan]

消息队列不是能强制消费顺序吗？