系列目录
一、回顾
1.1 回顾
分布式从来都不是简单的东西。为此写本系列文章也耗费了笔者大量脑细胞,从第一节3月底到总结篇的6月初,耗时2个多月...用经验,结合学习、测试,总算完结了。
本系列从原理、规范、组件支撑、简单样例、源码剖析多角度分析分布式事务,让大家对分布式事务有正确的概念,行之有效的实操能力、常用解决方案,底层源码的深入剖析。
1.2 目标
如果说分布式事务这一块100分的话,理论最少占了40%,实践只占60%甚至更少。一个成熟的程序员应该清楚,分布式这一块有哪些概念原理,常见解决方案。遇到问题可以一眼就看破虚妄,找到问题所在,甚至直接脑子里就有对应的实现方案。
二、灵魂问答
对于分布式事务,常见问题:
2.1.什么是事务?
事务(Transaction)是数据库区别于文件系统的重要特性之一。目前国际认可的数据库设计原则是ACID特性,用以保证数据库事务的正确执行。Mysql的innodb引擎中的事务就完全符合ACID特性。
事务根据业务场景不同可分为本地事务,分布式事务。
2.2.什么时候需要加 本地事务/分布式事务?
当需要多个增删改业务操作,同时成功或失败回滚时。如果操作的是一个RM(资源管理器),那么就是本地事务。如果操作多个RM,那就是分布式事务。
2.3.本地事务如何实现?
大部分情况下,一个服务操作一个数据库,这就是本地事务(本地事务飞机票)。ACID特性由数据库提供支持,比如mysql innodb引擎。如下图所示(网上的图,挺好直接用):
spring 提供了2种方式实现:
- 编程式:基于transactionTemplate去实现,适合手动精准控制事务的场景,少用。
- 声明式事务注解:@Transactional加在serviceImpl的方法上即可,这也是常用的方法。
2.4.分布式事务如何实现?
当遇到复杂业务调用时,可能会出现跨库多资源调用(一个事务管理器,多个资源)/多服务调用(多个事务管理器,多个资源),期望全部成功或失败回滚,这就是分布式事务,用以保证“操作多个隔离资源的数据一致性”。
分布式业务场景下,诞生了DTP模型、XA协议,以及引申出来的TM与RM之间的二阶段提交、三阶段提交。以及后来的CAP理论,BASE理论,大部分情况下为了追求性能,我们不会追求强一致性。
强一致性:如果应用服务器不支持分布式事务,那么可以借助第三方事务管理器实现,比如分布式事务(四)简单样例Spring Boot+Atomikos(TM)+Mybatis(ORM)+Mysql(DB)。
最终一致性:多种解决方案(具体见分布式事务(一)原理概览第六节)
- 正向幂等重试+反向异步回调(最大努力通知型)
- 可靠消息最终一致(异步确保型)
- TCC(两阶段补偿型)
三、不足
1.分布式的场景很多,不可能把每种源码都写出来。比如第一章的”最终一致性解决方案“,没有附上相关源码,读者可以根据方案介绍自行实现。
2.个人能力有限,有写的不对的地方,烦请指出,共同提高,壮哉我大Java!
如果你觉得本文对你有点帮助的话,记得在右下角点个“推荐”哦,博主在此感谢!