Seate分布式锁

XA模式

在第一阶段资源协调者（TC）会向资源管理者（RM）发出一个准备的请求，RM开始处理自身的业务，处理完成后不提交事务，而是向TC响应一个执行结果，表明自己成功还是失败，如果成功后则TC向RM发出提交事物的请求，RM此时提交事务，若失败则发出回滚的请求，RM就回滚

Seate的XA模式（强一致性）

开始TM向TC请求开启全局事务，TM调用每个RM分支，每个RM向TC注册自己分支事物，RM开始执行业务SQL，执行完成后，不提交事务并向TC报告事务的状态，业务执行完成后，TM向TC表明各个RM分支已经结束，此时TC检查分支事物的状态来决定是回滚还是进行提交事务。

优点：

（1）能够保证强一致性，满足ACID原则

（2）常用的数据库都支持，如mysql，实现比较简单且没有代码的侵入

缺点:

（1）因为第一阶段需要锁定资源等待其他分支执行完成，所以性能比较差

（2）依赖关系型数据库实现事物

Seate的AT模式（最终一致性）

开始TM向TC请求开启全局事务，TM调用每个RM分支，每个RM向TC注册自己分支事物，RM开始执行业务SQL，执行完成后并提交事务，向TC报告自己的事物状态，在提交事务时会记录更新前后的快照到undo log表当中，TM发现事务完成后，向TC提交或回滚事务的请求，此时TC回去检查每个分支事务的情况，如果正常则删除undo log对应的数据,否则会通过undo log进行回滚。

AT模型的脏写问题

并发模式下，如果事务一先获取锁，将id为1的money由100减为了90，此时事务二进来，但获取不到锁，所以等待，事务一执行完毕后释放数据库锁，事务二此时获取到了锁，又将id为1的money由90减为80,此时事务一需要回滚，但是事务二正在获取锁，所以等待事务二释放锁后，事务一拿到锁后就根据undo log中的快照进行回滚，id为1的money此时就变为了原来的100，从而出现了脏写。

解决方法

情况一

在事务一执行业务SQL时，在提交事务前先获取全局锁，即将当前事务id和当前table（表）和当前行id进行记录，在执行完之后，事务二来修改，但在获取全局锁时发现已经有其他事务获取到了锁，所以会进行重试获取全局锁，此时如果事务一需要回滚，在获取数据库锁的时候就会失败，因为此时事务二占有数据库锁，但不会造成死锁，因为事务二在重试获取全局锁只有30次，并且每次10毫秒，所以当事务二获取全局锁失败后，就会进行事务回滚，此时事务一就占有了锁并进行回滚，所以此时回滚就不会照成脏写，因为事务二并没有成功更新

情况二

如果此时来更新此数据的事务并没有交给seata管理，所以在修改数据时，并不会去检查是否能获取全局锁，所以此时更新会成功，但解决方法是，在事务一对数据进行更新时会记录更新前数据和更新后的数据，如果事务一进行回滚时，会去将当前数据和事务一修改后的快照进行比较，如果相同则正常回滚，如果不同则会记录异常，发送警告，并进行人工介入，而不会进行正常的回滚

优点:

（1）一阶段完成直接提交事务，释放数据库资源，性能比较好

（2）利用全局锁实现事务隔离

（3）没有代码侵入，框架自动完成回滚和提交

缺点:

（1）两阶段之间属于软状态，属于最终一致性

（2）框架的快照功能会影响性能，但比XA模式要好的多

TCC模式（最终一致性）

大致流程