分布式事务(六)总结提高
系列目录
一、回顾
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!
相关文章
- C# 9.0 终于来了, Top-level programs 和 Partial Methods 两大新特性探究
- Newtonsoft 六个超简单又实用的特性,值得一试 【下篇】
- Newtonsoft 六个超简单又实用的特性,值得一试 【上篇】
- HashSet扩容机制在时间和空间上的浪费,远大于你的想象
- foreach 集合又抛经典异常了,这次一定要刨根问底
- C#9.0 终于来了,带你一起解读 nint 和 Pattern matching 两大新特性玩法
- C#9.0 终于来了,您还学的动吗? 带上VS一起解读吧!(应该是全网第一篇)
- MySql轻松入门系列——第二站 使用visual studio 对mysql进行源码级调试
- 字符串太占内存了,我想了各种奇思淫巧对它进行压缩
- MySql轻松入门系列——第一站 从源码角度轻松认识mysql整体框架图
- 自定义值类型一定不要忘了重写Equals,否则性能和空间双双堪忧
- 使用PInvoke互操作,让C#和C++愉快的交互优势互补
- 阿里短信回执.net sdk的bug导致生产服务cpu 100%排查
- List的扩容机制,你真的明白吗?
- BitArray虽好,但请不要滥用,又一次线上内存暴增排查
- 记一次排查线上程序内存的忽高忽低,又是大集合惹祸了
- 追了多年的开发框架,你还认识指针吗?
- 还不明白可空类型原理? 我可要挖到底了
- 不要把异常当做业务逻辑,这性能可能你无法承受
- 内存迟迟下不去,可能你就差一个GC.Collect