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

[chaleaochexist]

还是说没有解决方案

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

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

请问如何解决?

[xuanbg]

@MoYi123 有没有一种可能，会有一个库存预警系统？这个系统不至于连个负数都会导致异常吧？对了，使用除法时，你还得当心除数为 0 。难道你从来都不先判断除数为 0 的情况？不会吧？不会吧？

[chaleaochexist]

@xuanbg #40 那你就给好好讲讲呗.
总结一下你的思路. 提高你的写作能力. 顺便还帮助了别人.至少我是感谢你的.
你在这个帖子下面打了这么多字 大部分都没什么营养. 至少我没多大收获.

[craftx]

分布式事务，全部成功后，再提交
或者支付失败后，回滚

[yankebupt]

给每个苹果打上 GUID ，减和补的时候查
那些违法作弊菠菜网站防黑的时候都会这样，才会做到筹码只赚不亏
上面发下来一个盈亏值，token 定死，你怎么折腾都行，赢超过这个数全部无效，比这个少或者输了，你发一条，对方收钱的时候倒不会含糊。

前提你真的是库存

[ChoateYao]

先实时扣库存，然后记好扣减记录，会需要回滚的时候，直接用该记录回滚。

回滚使用队列

[AbrahamGreyson]

加锁 + 确认啊， 或者队列， 微服务就分布式锁 或 redis 被， 一致性问题是很通用的，有很成熟的方案～

[yinmin]

@chaleaochexist
把你的问题丢给 GPT4 ，回答的不理想，提示了一下“参考信用卡预授权”，这次回答的不错，提供给 OP 参考：

在实际的电商系统中，通常会有一个“锁定库存”的操作，这也被称为“预扣库存”。这个操作的目的是在用户下单时先将库存锁定，以防止在用户支付过程中商品被其他用户购买。

这个流程通常是这样的：

1. 用户下单时，系统先进行预扣库存操作，即临时锁定用户购买的商品数量。这个操作通常会在数据库中标记出来，以区分实际的库存和预扣的库存。

2. 用户完成支付后，系统会将预扣的库存转变为实际的库存减少。

3. 如果用户在一定时间内没有完成支付（例如在 15 分钟或 30 分钟内），系统会自动取消订单，并将预扣的库存释放回去。

这种方式可以有效地解决并发下单的问题，保证用户在下单时商品的库存是足够的。同时，也可以防止因为支付失败而需要回滚库存的问题，因为在用户支付失败时，系统只需要释放预扣的库存即可。

[chaleaochexist]

@yinmin
谢谢你的回复 仔细推敲也不太对
还是超时问题.

和卖苹果例子一样只不过不减库存而是锁定和解锁
其实是一样的原理.
还是 +- 1 操作
如果每个苹果都有一个唯一 ID. 还是会有 解锁一个没加锁苹果的问题. 也就是阻塞.

[yinmin]

@chaleaochexist 应对电子商务大流量并发冲突，或者每个苹果有唯一 ID 带来的阻塞，还有一种思路：用消息队列(类似 rabbitmq)，服务器配置成单线程读队列处理库存，理想状态下 1 分钟能处理几万交易，能满足中小电商的需求。

[chaleaochexist]

@yinmin 谢谢

[chaleaochexist]

@yinmin #49 仔细读了一遍感觉不对, 还是 GPT 的回复....那就没有说服力了... 几万

[alexsunxl]

这个跟微服务完全没关系的。是业务层的事务问题。
用啥方案都不是关键了，但是一定要关注各种异常处理。

[xiaoyuesanshui]

中间加一个缓冲环节

库存--缓冲--已销售


下单库存-1
缓冲+1

付款成功
缓冲-1
已销售+1

付款失败
缓冲-1
库存+1

[chaleaochexist]

@alexsunxl 单体部署 数据库事务约束就可以了.