脱离事务后，乐观锁怎么保证当主业务失败后所有关联操作都一定会回滚的

[dzdh]

还拿经典的下单逻辑来说。

我的整个逻辑可能是这样的：

• update goods set stock=$n where id = $ID and stock=$old_stock 更新库存
• update coupons set used = 1, order_id = $n where id = $ID and used = 0 and order id is null
• update credits set credits = $n where id = $ID and credits = $old_credits

假设，如果第一个 sql 成功，第二个 sql 成功（重试 5 次，间隔 1 秒），第三个失败了。然后 mysql 崩了（无论因为网络啊、进程啊、硬盘满了啊各种概率因素）导致后续的 sql 都不可能执行成功，而且崩了至少有一小时。

怎么保证在 1 小时后，刚下的订单为失败？或者让后续逻辑能继续执行？

[cheng6563]

脱离事务，只能从头开始重试，并且挨个检查每条数据的变化日志咯。

[dzdh]

@cheng6563 是吧。就只能自己造一种检测是吧。比如造一个 task 表。每个阶段都干了啥，然后定时检测 task 表。

[sujin190]

乐观锁本来就不支持回滚这种情况，既然需要能一起回滚那你要的就是事务，然后你还看不上 mysql 事务，非要自己在应用层自己搞个事务，这不是自己给自己找麻烦作死么。。

[dzdh]

@sujin190 老系统 myisam

[bk201]

你可以借助有事务的系统来辅助实现没事务系统的事务功能。

[sujin190]

@dzdh #4 既然如此何不直接考虑改存储引擎呢？反正一般来说应用层其实不会有啥区别，其他方案估计都会比这更复杂

[wu00]

需要实现事务的业务点不多就选#5 ，否则选#6

自己造轮子能玩死你，脱离数据库你得解决脏读、幻读、重复读那些玩意儿
就算引入分布式事务框架(seata 、dtm 等)，也要自行解决幂等、空补偿等非预期情况

[dddd1919]

锁用来保证独占资源和排他，操作回滚本来也不是锁的功能，如何保证呢？

如果非要脱离事物，那也简单，把所有 update 的数据做成一行，既不用显式加锁，也不用事务🐶