各大分布式事务框架对比

[luky116]

名词解释:

数据库有六种日志分别是：重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、 慢查询日志(slow query log)、一般查询日志(general log)，中继日志(relay log)

事务类型: XA 因为 事务资源 感知并参与分布式事务处理过程，所以 事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。而TCC,Saga,AT属于补偿型事务

补偿型事务: 在一个长事务（ long-running ）中 ，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。
目前一个叫WS-BusinessActivity的组织提供了一种基于补偿的long-running的事务处理模型。服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性

ps: 对于MySQL事务 有兴趣可以阅读本人的笔记
以MySQL为例: https://www.yuque.com/chengxingyuan/vffshx/wi7z7y
一般在不同的业务场景应按需引入不同的事务形态 优先级顺序为:
单机事务 > 基于消息的事务 > 基于补偿的事务

功能对比

特性	DTM	SEATA
支持语言	Golang 、python 、php 、c# 及其他	Java
异常处理	子事务屏障自动处理	事务异常切面拦截，对于数据库连接超时，各个tm时区不一致等外部问题 需要手动处理
TCC 事务	✓	✓
XA 事务	✓	✓
AT 事务	✗	✓
SAGA 事务	简单模式	状态机复杂模式
事务消息(可靠消息模式)	✓	✗
通信协议	HTTP 、GRPC	四层私有协议

事务模式横向对比

特性	MySQL XA	Postgresql XA	LCN 模式	AT 模式	RT 模式
支持语言	无限制		Java	Java	PHP
使用难度	简单		困难	困难	简单
数据一致性	100%		强	中	100%
并发性能	中		低	中	高
业务入侵	无		无	低	无
sql 修复入侵	无		无	低	无
分布式事务嵌套	不支持		支持	支持	支持
子服务嵌套事务	不支持		不支持	不支持	支持
sql 事务嵌套	支持		不支持	不支持	支持
通信协议	不能跨服务		dubbo	dubbo	http
事务隔离级别	可重复读		未知	读未提交	读已提交
事务类型	长事务		长事务	短事务	短事务
死锁	多		多	少	少
orm 框架	适用		绑定	绑定	适用
支持 sql 语句	所有		未知	不支持多表和批量操作	绝大部分
脏回滚	无
存在
脏读	无
有

各个事务模式下的对比

所以接下来的对比会涉及到每个框架各个隔离级别的对比

隔离级别/发生情况	XA	TCC	Saga
SERIALIZABLE级别	读操作加读锁、写操作加写锁

|
|
| REPEATABLE READ级别 | 读是本地多版本不是全局多版本(脏读) |
|
|
| READ COMMITTED级别 |
|
| |
| READ UNCOMMITTED级别 |
|
| |

Continue..QwQ