还拿经典的下单逻辑来说。
我的整个逻辑可能是这样的:
假设,如果第一个 sql 成功,第二个 sql 成功(重试 5 次,间隔 1 秒),第三个失败了。然后 mysql 崩了(无论因为网络啊、进程啊、硬盘满了啊各种概率因素)导致后续的 sql 都不可能执行成功,而且崩了至少有一小时。
怎么保证在 1 小时后,刚下的订单为失败?或者让后续逻辑能继续执行?
1
cheng6563 2022-07-18 09:50:31 +08:00
脱离事务,只能从头开始重试,并且挨个检查每条数据的变化日志咯。
|
2
dzdh OP @cheng6563 是吧。就只能自己造一种检测是吧。比如造一个 task 表。每个阶段都干了啥,然后定时检测 task 表。
|
3
sujin190 2022-07-18 10:02:45 +08:00 via Android
乐观锁本来就不支持回滚这种情况,既然需要能一起回滚那你要的就是事务,然后你还看不上 mysql 事务,非要自己在应用层自己搞个事务,这不是自己给自己找麻烦作死么。。
|
5
bk201 2022-07-18 10:43:45 +08:00
你可以借助有事务的系统来辅助实现没事务系统的事务功能。
|
7
wu00 2022-07-18 14:13:03 +08:00
需要实现事务的业务点不多就选#5 ,否则选#6
自己造轮子能玩死你,脱离数据库你得解决脏读、幻读、重复读那些玩意儿 就算引入分布式事务框架(seata 、dtm 等),也要自行解决幂等、空补偿等非预期情况 |
8
dddd1919 2022-07-18 22:55:22 +08:00
锁用来保证独占资源和排他,操作回滚本来也不是锁的功能,如何保证呢?
如果非要脱离事物,那也简单,把所有 update 的数据做成一行,既不用显式加锁,也不用事务🐶 |