一. Mysql InnoDB事务原理:
I后写binlog
通过redo日志将所有已经在存储引擎内部提交的事务应用redo log恢复,所有已经prepare但是没有commit的transactions将会应用undo log做rollback。然后客户端连接时就能看到已经提交的数据存在数据库内,未提交被回滚地数据需要重新执行。
https://blog.csdn.net/Super_Anna/article/details/51926612
二. 分布式事物机制及原理
2.1 2PC(jta)
两阶段提交存在问题:
1) 同步阻塞问题。整个执行过程中,资源一直在阻塞;
2) 数据不一致问题。第二阶段提交时,若资管管理器1接收到提交命令并执行成功,资源管理器2未接收到提交命令,则出现数据不一致问题;
3) 单点故障。事务管理器在第二阶段出现故障时,资源管理器1和资管管理器2均处于锁定事务资源的状态中。
三阶段解决的问题及存在的问题:
1) 解决的问题-部分解决了同步阻塞问题。在第一阶段不阻塞资源,仅在第二阶段和第三阶段阻塞资源;
2) 解决的问题-解决协调器单点故障问题。两阶段提交只有协调器超时,而三阶段提交既有协调器超时也有资源管理器超时,规避了两阶段提交中的协调器单点故障问题;
3) 未解决的问题-数据不一致问题。资源管理器在第二阶段后未收到roolback或commit命令时,在超时后均会提交。若此种情况:资源管理器1收到回滚并执行成功,资源管理器2未收到命令。超时后commit,则出现数据不一致。
假定超时后默认回滚,那么在资源管理器1收到提交命令并执行成功的情况下,资源管理器2未收到命令,超时后回滚,一样出现数据不一致问题。
http://www.cnblogs.com/binyue/p/3678390.html
2.2 TCC
https://www.cnblogs.com/jajian/p/10014145.html
以用户sku订单为例:需要做库存变动、会员积分变动;
try1: | confirm1: | cancel1: | ||||||||
原数据 | 预变动 | 原数据 | 预变动 | 原数据 | 预变动 | |||||
库存表 | 100 | -1 | 库存表 | 100-1=99 | 0 | 库存表 | 100 | 0 | ||
try2: | 原数据 | 预变动 | confirm2: | 原数据 | 预变动 | cancel2: | 原数据 | 预变动 | ||
积分表 | 200 | 2 | 积分表 | 200+2=202 | 0 | 积分表 | 200 | 0 |
2.3 本地消息表
2.4 MQ 事务
三.分布式锁
https://blog.csdn.net/xlgen157387/article/details/79036337
四.redis集群迁移
https://blog.csdn.net/u011535541/article/details/78834565