为什么Seata有了AT模式还去做XA的支持
首先我们应该从AT去做判断,为什么Seata有了AT模式还去做XA的支持 从视角出发:首先,我们来总结下AT模式,首先所有的事物发起,都是从TM(不仅AT) 且数据的读已提交只能在应用中见效(用户自行开发的系统),对资源的查看,无法做到全方面 而XA可让资源也感知到自身已处于全局事务中,对资源的隔离性可由数据库本身来实现,满足 全局一致性 从入侵性,数据库支持角度:业务无入侵的更彻底,少于2个服务的操作,仅使用本地事务即可满足一致性,而AT需要 全局锁来保证隔离性,所以无论是1个服务,单库的操作,还是n个服务都需要开启全局事务来保证 隔离性。对数据库的支持,如果AT需要支持mysql,pgsql,oracle以外的数据库,需要做适配,并且 对复杂sql的解析成本更大,开发效率低,支持的sql数量少,XA可全方位支持数据库的sql语句 多语言支持,如果你有java应用已经使用了seata xa那么本地数据库已经帮我们保证了隔离 性,即便其余seata不支持的语言和java并行处理下,数据也不会出现不一致的情况。 数据锁定:在整个事务处理过程结束前,涉及数据都被锁定,读写都按隔离级别的定义约束起来。 AT 模式使用 全局锁 保障基本的 写隔离,实际上也是锁定数据的,只不过锁在 TC 侧集中管理 解锁效率高且没有阻塞的问题,且XA本地数据库可能持有间隙锁,造成锁的粒度更大,锁定更多无辜数据 死锁(协议阻塞):XA prepare 后,分支事务进入阻塞阶段,收到 XA commit 或 XA rollback 前必须阻塞等待。如果没有一个靠谱的协调者存在,比如abc三个库的数据被二阶段决议为提交,此时ab收到的指令,提交后,c库在收到指令后挂了,并没有提交xa事务,或者协调者没有做到二阶段重试,那么这个没有提交的xa事务将会一直 持有锁,造成死锁的局面 性能差:性能的损耗主要来自两个方面:一方面,事务协调过程,增加单个事务的 RT;另一方面,并发事务数 据的锁冲突,降低吞吐。其实主要原因就是上面的阻塞跟数据锁定造成,因为xa的一阶段并非提交,如果一阶段都是提交的场景下,由于At模式的一阶段提交,at的性能是优于xa,因为它锁在tc一侧集中释放,无需多个库进行本地的锁释放 (编辑:52站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |