大数据分布式事务的深入理解？，我了解到的面试的一些小内幕

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

本地事务的理解，拿上面的转账例子来说，如果刚好A账户和B账户在同一家银行的同一个数据库里，那么他就满足了一个本地事务的基本条件；也就是说我要执行这两个账户的加减操作只需要在一个程序中就能完成，而且这两个操作彼此之间的顺序和结果是可知的，那么我们在程序内部就可以很容易实现这个事务操作；

但是如果A账户跟B账户分别在两家不同银行的不同数据库中就没有办法做到像刚才那样在同一个程序里同时去操作A账户和B账户了，我们只能先在A账户对应的银行进行第一步操作，然后再在B账户对应的银行里进行第二步操作，但还会有个问题需要注意那就是操作A账户跟操作B账户这两个操作彼此之间的结果和顺序是不可见的，而这就是分布式事务的场景；此时就只能找一个中间人来帮忙协调这个事情，而这个中间人就是银联，于是我们只需要把转账这个行为告诉银联，然后银联来具体负责向A银行账户扣钱再去B银行的账户加钱；但是这个过程其实相比于刚才的本地事务要复杂的多，因为涉及到了三方的沟通，银行A、银行B、银联，这里面一旦有某一环节处理不好就容易导致A、B账户金额的不一致；那么为了保证分布式事务的可靠性就出现了两阶段提交和三阶段提交的实现方案。

两阶段提交就是把这个多方沟通协调的过程根据沟通顺序划分为两个阶段；提交就是把写在内存中的数据再次写入到磁盘中；回滚是把在内存中修改的数据进行撤销。A账户跨行向B账户转账，第一阶段为银联收到转账申请后先向A账户所在银行发起扣钱操作，A只执行不提交也就是只在内存中对金额进行扣减但是不写入到磁盘中然后把执行成功的消息告诉银联，接着银联再向B的所在的银行发起加钱操作也只是在内存中对账户金额进行增加并不写入磁盘，然后再把执行成功的消息也告诉银联，第一阶段也可称为投票阶段，如果A、B操作都成功则投票成功，否则为失败。然后是分布式事务的第二个阶段，当银联分别收到A、B银行的操作反馈之后，确保所有步骤都没有问题便开始向A银行和B银行发出提交通知，让A银行和B银行分别将刚才在内存中修改的金额写入到磁盘中进行持久化，而这个阶段就叫做事务的提交阶段。如果两个阶段其中任何一个阶段一旦出现了某个操作的失败，那么银联就会在第一时间想办法不让A、B的账户余额变化写入磁盘中，就是进行事务的回滚操作，两阶段提交是用来保证分布式事务一致性的一种策略，但也有一些不完善的地方，然后就有三阶段提交。

三阶段提交比两阶段提交多了一个事务开始前的询问阶段，比如当银联决定开始对A、B账户进行转账操作前，为了严谨他会先询问A、B账户所在的银行当前是否可以执行对应账户余额的增减操作，如果当前A银行或者B银行的数据据刚好在维护或者升级，那么就可以第一时间通过这个第一阶段的询问来得知，这样就可以提前终止本次转账操作，这么做的好处在于提前对各个要通讯的对象系统状况有个初步的了解，如果通信对象存在网络故障、系统负载过高等问题就可以提前知道避免了后续无谓的操作，而剩下的两个阶段跟两阶段提交的步骤基本一致，三阶段提交还优化了两阶段提交的超时机制，比如在原来等银联发送提交通知给A、B银行时如果协调者银联挂了，那么银行A和银行B就只能在那里等待并等银联恢复通信；而三阶段提交的机制则优化了这一点，如果最后一个阶段银联因为各种原因无法正常通信超过一段等待时间后那么银行A和银行B就可以在不用收到银联提交通知的情况下自己完成各自的提交操作，从而进一步提高分布式事务的一致性成功率。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**