最终一致性库存解锁逻辑

分布式事务-最终一致性库存解锁逻辑

一、Seata的不足#

Seata的AT模式是二阶段提交协议（2PC），第一阶段将本地事务直接提交，第二阶段想要回滚的时候，是通过回滚日志（日志表）做的反向补偿，数据库原来是多少又改了回来。

Seata应用场景：后台管理系统，比如添加商品，优惠、库存、积分、会员要成功都成功，要失败都失败，对于并发性能不高的可以使用Seata来处理分布式事务。

如果并发性能要求很高的，比如下单，则需要使用最终一致性，RMQ发消息，保证消息的可靠性（发送端和接收端确认），不能达到强一致性，但能达到软柔性事务的最终一致性。

下单属于高并发场景，为了保证高并发，不推荐使用seata，Seata用了很多锁机制，因为是加锁，相当于把并发变为串行了，如果多个订单下来，就得进行排队，等待上一个人处理完了，释放了锁，才能继续下单，这样系统可能就没法用了，提升不了效率，可以发消息给库存服务。

二、高并发场景#

在锁库存的时候，需要给数据库增加记录，锁的数量和SKU，以及仓库，如果锁失败，库存锁表里边没有这条记录，可以使用定时任务来处理，不过使用定时任务来处理，是非常麻烦的事情，可以使用延时队列来处理，延时队列做一个定时工作。