分布式事务LCN和seata对比

一、LCN实现原理
1.发起方与参与方都与我们的LCN管理器一直保持长连接；
2.发起方在调用接口之前，先向LCN管理器申请一个全局的事务分组id；
3.发起方调用接口的时候在请求头中传递事务分组id；
4.参与方获取到请求头中有事务分组的id的，则当前业务逻辑执行完实现假关闭，不会提交或者回滚当前的事务。
5.发起方调用完接口后，如果出现异常的情况下，在通知给事务协调者回滚事务，这时候事务协调则告诉给参与方回滚当前的事务。
 

二、Seata实现原理
1.TM（发起方）连接到我们的TC事务协调者，创建一个全局的事务的xid，保存到ThreadLoacl中；
2.TM（发起方）和RM(参与方)都被Seata的数据数据源实现代理，在原生的sql之前和之后保存原来和修改后日志到undo_log中，方便后期实现回滚。
3.TM（发起方）使feign客户端调用接口时候，在ThreadLoacl中获取xid，设置到请求头中；
4.RM(参与方)从请求中获取到该xid，设置到ThreadLoacl中，同时也会向seataserver注册该分支事务。
5.TM(发起方)将当前本地事务的结果，告诉给协调者TC，协调者TC在通知所有的分支是否回滚。
6. TM(发起方)如果调用接口成功之后抛出异常的情况下，告诉给协调者TC，协调者TC在通知所有的分支根据根据全局的xid和分支事务的id 查询分支数据源的undo_log日志表逆向生成sql语句实现回滚，同时删除对应的undo_log日志
7. TM(发起方)如果调用接口成功之后没有抛出任何的异常，告诉给协调者TC，协调者TC在通知所有的分支根据根据全局的xid和分支事务的id 查询分支数据源的 删除对应的undo_log日志表

Seata原理分析
1.发起方TM会向我们的TC协调者申请一个全局的事务id，保存到threadlocal中；
2.TM和RM都会被Seata代理数据源，写入原来和修改后内容保存到undo_log表中；
3.TM从请求头中传递该全局的事务id给RM，RM从请求中头中获取到该全局事务id，并且注册该分支。
4.如果TM调用接口成功之后，如果报错的情况下则通知给协调者，协调者在告诉所有的分支都开始回滚，直接根据本地事务id+xid查询undo_log表 ，逆向生成sql语句回滚，同时删除该undo_log日志。
5.如果TM调用接口成功之后，如果没有报错的情况下则通知给协调者，协调者在告诉所有的分支都开始提交事务，直接根据本地事务id+xid删除对应的undo_log表记录即可。

undo_log表每个数据库都要

前置镜像 select * from order state = 0 原来的值
Update order set state(1) where userID=1 订单服务实现 1
后置镜像 1 之后的值
逆向的话 Update order set state(0) where userID=1

要注册到nacos上实现高可用
 

三、Seata与Lcn的区别

1、seata没有管理页面

2、LCN配置简单易上手

3、基本实现的思路差不多，唯一区别在于回滚的方式 LCN采用代理数据源假关闭连接，暂时不提交本地事务，但是容易造成数据的死锁。
4、Seata采用undo_log的形式逆向生成sql语句实现回滚，避免死锁现象但是容易出现脏读。