前言
在前面的博客中,我们依次讲解了Seata AT模式的原理及使用方式,上一篇博客中我们讲解了如何在Spring Cloud中集成Seata TCC模式,那么就有一个疑问,我们在实际项目中,应该选择哪种分布式事务解决方案呢?
优缺点对比
AT模式 | TCC模式 | |
新手入门难度 | 容易 | 适中 |
业务侵入性 | 小 | 大 |
性能 | 一般 | 高 |
编码工作量 | 一般 | 大 |
是否支持复杂sql | 不完全支持 | 支持 |
1.【新手入门难度】AT模式的代码编写方式和平时一样,只需要在TM入口加上@GlobalTransactional即可,开发人员按照正常逻辑编码完全没有问题;TCC模式的设计思路和AT模式完全不一样,TCC的一阶段和二阶段都是需要开发人员自行编码处理的,在业务处理上需要按照TCC的资源预留方式开发,学习成本上较AT模式要高上一个级别,所以在新手入门难度这一点上,AT模式更加容易;
2.【业务侵入性】AT模式是业务无侵入的,开发人员只需要关注业务SQL即可,二阶段的处理完全由Seata框架托管;TCC模式无论是一阶段还是二阶段,全部的
Try
、Confirm
、Cancel
逻辑全部需要开发人员根据业务需求自行编码;所以在业务侵入性上,AT模式更好;3.【性能】AT模式在一阶段处理完毕后,还会存在行锁,此时如果有其他事务需要操作被行锁锁住的记录时,会被阻塞,直至分布式事务结束才能拿到行锁;TCC模式因为是资源预留的设计方式,只有在一阶段预留资源时存在竞争,一阶段处理完毕后,不管分布式事务是否结束,后续都不存在资源竞争问题,所以TCC模式相较于AT模式,性能是更好的;
4.【编码工作量】AT模式只关注业务SQL,TCC模式需要根据业务设计来实现资源预留方案,二阶段提交和回滚逻辑全部需要开发人员编码实现,所以编码工作量上几乎是AT模式的2~3倍;
5.【是否支持复杂sql】AT模式需要针对提交的业务SQL进行拦截,并进行解析,根据对应的业务SQL生成前后镜像,这也就意味着AT模式并不能支持很复杂的业务SQL;TCC模式不用关心具体的业务SQL,Seata只会根据开发人员编码分别调用
Try
、Confirm
、Cancel
方法,所以在这一点上,TCC模式更胜一筹;
该如何选择
根据上述AT模式与TCC模式的对比,我们可以了解到,如果业务功能对性能要求很高,并且属于公司的核心业务,那么建议采用TCC模式;如果该功能对性能要求一般,建议采用AT模式;有一点需要提醒的是,AT模式和TCC模式是可以在一个项目中共存的,所以小伙伴们完全可以根据具体的业务需求选择任意的分布式事务解决方案;感兴趣的小伙伴还可以上github下载我准备好的相关案例:awesome-seata。