事务及锁

一. 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