seata的四种模式

首先吧 分布式事务使用的场景有限 因为引入分布式事务需要考虑比较多的复杂性 所以推荐在能用本地事务解决的情况下 尽量避免使用分布式事务

如果决定要使用分布式事务 则需要小心考虑业务场景是否能避开分布式事务的缺陷

分布式事务有很多解决方案 多数情况下原理相似 这里以seata为例 通过分析seata的四种模式 来窥探分布式事务的复杂性

四种模式都采用2阶段提交的模型(Two-phase Commit，2PC)​ 大概就是 1阶段本地提交 2阶段全局提交或回滚

AT模式 生产上最有可能使用的模式，基本上做到了业务上零入侵。1阶段本地提交依赖如mysql的acid事务，本质就是本地commit。1阶段提交后，同时seata的事务框架会持久化数据变更前和变更后的信息。2阶段在事务框架确认没有问题的后就全局提交（因为数据在1阶段已经真实提交了，所以此时只是删除掉存储的变更信息），2阶段如果发生问题，就执行全局回滚，此时就用上了存储的变更信息，自动生成回滚的sql，并执行。

这里有些概念要注意 seata自带了一个事务框架 里面大概涉及到全局锁 事务协调器 事务管理器之类的组件 但是都属于seata层级的 和数据库本身的事务并无关系（XA模式例外）。

到这里，其实二阶段提交的模型已经体现出来了。剩下3种模式 大体框架也是这样 只是在提交 回滚 事务管理 上的实现有区别。

AT模式：数据库1阶段本地提交 2阶段自动回滚 使用全局锁
TCC模式：自定义提交 自定义回滚 不依赖数据库本身的事务 使用全局锁
SAGA模式：和TCC模式基本相同 也是提交和回滚自定义 但是有个重要的区别：在全局事务管理中 没有用全局锁 这就意味着saga模式没法保证写的隔离性
XA模式：依赖数据库的XA协议 与AT模式思路是一样的 只不过提交和回滚对接了数据库的XA协议 由XA协议保证提交和回滚(AT模式的提交和回滚由seata定义的事务管理器处理) 且XA是强一致的（XA协议提供,XA协议的全局锁是读写隔离的,所以XA是长事务模式）

通过以上模式 可以总结一些知识点：
1.seata分部式事务总体是基于2阶段提交的
2.基于2阶段提交的分布式事务 除XA模式外 存在 读未提交 的问题
3.AT TCC XA都使用了全局锁 可以保证写隔离（不会发生脏写）,SAGA没用使用全局锁,会出现脏写问题
4.除AT XA模式，其他模式对业务代码入侵性强，增加了开发成本和代码复杂度。

通过以上总结的知识点，不难看出seata使用场景有限的原因。除XA外的3种模式都有 读未提交 的问题,XA模式虽然读写隔离，但是属于长事务模式，性能较本地提交很差。这不是seata独有的问题，应该说是分布式事务模型存在的缺陷，故在选择分布式事务的情况下，要考虑的方面比较多。

在实际业务场景上，核心业务很难接受读未提交带来的后果，宁愿牺牲性能也要尽可能保证数据的一致性。边缘业务由于数据没那么重要，用分布式事务这种相对较重的方案，也显得没那么必要。综上所述，seata就显得有点鸡肋。

在核心业务中，为保证强一致和性能，一种方案是在微服务划分的时候，把核心业务尽量划分为一个整体（即一个服务），然后用本地提交保证性能。也可以使用分布式锁或数据库字段标识 加上 数据库本地事务来保证强一致性。