本文探讨了分布式事务中遇到的问题，如超卖问题，以及单体架构下跨库事务的挑战。介绍了两阶段提交协议作为解决方案，但指出其可能存在的并发性能问题和不稳定性。此外，还提到了CAP理论，并提出两阶段补偿型方案作为另一种应对策略，适合非高并发场景。
事务是一组 SQL 语句，它们是一个执行单位
下单调用交易服务创建订单成功，然后调库存服务，结果库存减失败了，导致超卖，这种就是典型的分布式事务问题。这种场景无法像单体结构的服务那样用 @transational解决。
跨库事务，单体架构，由于数据量过大进行分库，涉及跨库操作， 用@transational能解决吗？
不能。怎么解决呢，用atomikos框架。
两阶段提交协议
有一个中间协调者，
第一阶段：修改完订单表不马上提交事务，即执行完修改订单的sql之后，把执行sql是否成功的结果告诉给协调器，然后去减库存，然后把sql执行是否成功的结果告诉协调器
第二阶段：如果两次sql的执行结果都是成功，然后协调器通知每个库去提交事务，提交失败会重试，重试一定的次数还没成功就会记录一条日志，定时再重试，最后还不成功只能人工介入了。
这种事务问题不可能100%解决，只能提高解决概率。另外这种事务锁表的时间比较长，不适合并发场景，会导致大量的等待。
cap理论
两阶段补偿型方案，增加一个中间状态
阶段2才真正修改库，冻结-核销-回滚，核销失败可以重试，这种没有大事务问题。
2个步骤，在非高并发场景，性能比跨库操作性能要慢
扫一扫
262
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
