总结
在清楚了各个大厂的面试重点之后，就能很好的提高你刷题以及面试准备的效率，接下来小编也为大家准备了最新的互联网大厂资料。
（本分支图片来源于：面试官问我知道的分布式事务，我一口气说了六种）
2PC
二阶段提交，一种强一致性设计：
一荣俱荣，一损俱损。
第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。
眼尖的小伙伴多看两眼，就能看出一个问题来。我先不公布，拿张图挡一下，要自己想的就先别划下去。
有没有想过，协调者故障，或者事务失败了呢？
协调者压力可是很大的哦，因为它要为身后那些数据库撑起一片天哈。
如果协调者事务失败，这里有两种情况。
第一种是第二阶段执行的是回滚事务操作，那么答案是不断重试，直到所有参与者都回滚了，不然那些在第一阶段准备成功的参与者会一直阻塞着。
第二种是第二阶段执行的是提交事务操作，那么答案也是不断重试，因为有可能一些参与者的事务已经提交成功了，到最后真的不行只能人工介入处理。
协调者单点故障分析
Switch 协调者挂的时间：
case 发布准备命令前{
挂吧，事务还没开始，去修复它
};
case 发布准备命令后{
锁定了资源的事务参与者将可能陷入阻塞，因为资源被锁定了嘛
}
case 发送回滚事务命令前{
同上
}
case 发送回滚事务命令后{
很大概率没事儿，但是出现网络分区就有可能会有些参与者收不到命令阻塞
}
case 发送提交事务命令前{
好了，全死了
}
case 发送提交事务命令后{
同上上
}
default{
}
}
协调者单点故障解决方案
了解一下主从嘛。通过选举赶紧的再来一个协调者顶上去。
还是对上面进行一个划分处理哈：
Switch 协调者挂的时间：
case 发布准备命令前{
没事，小意思
};
case 发布准备命令后{
每个参与者自身的状态只有自己和协调者知道
这时候就需要日志了，不然新协调者哪里知道谁OK不OK啊
}
case 发送回滚事务命令前{
同上
}
case 发送回滚事务命令后{
同上
}
case 发送提交事务命令前{
这个好办，统统滚回去吧
}
case 发送提交事务命令后{
同上上
}
default{
}
}
2PC 是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低，并且存在单点故障问题，在极端条件下存在数据不一致的风险。
但是也不能说人家就没用是吧，那不是还有个场景必须要强一致性嘛，那个ACID的那个。
数据库
3PC
相比于 2PC 增加了预提交阶段。
相比于 2PC 有什么升级？
1、准备阶段的变更成不会直接执行事务，而是会先去询问此时的参与者是否有条件接这个事务。因此性能会差一些，而且绝大部分的情况下资源应该都是可用的。
2、预提交阶段的引入起到了一个统一状态的作用，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干。
3PC 通过预提交阶段可以减少故障恢复时候的复杂性，但是不能保证数据一致，除非挂了的那个参与者恢复。
TCC
2PC 和 3PC 都是数据库层面的，而 TCC（Try - Confirm - Cancel） 是业务层面的分布式事务。
面试结束复盘查漏补缺
每次面试都是检验自己知识与技术实力的一次机会，面试结束后建议大家及时总结复盘，查漏补缺，然后有针对性地进行学习，既能提高下一场面试的成功概率，还能增加自己的技术知识栈储备，可谓是一举两得。
以下最新总结的阿里P6资深Java必考题范围和答案，包含最全MySQL、Redis、Java并发编程等等面试题和答案，用于参考~
重要的事说三遍，关注+关注+关注！
更多笔记分享
99269)]
更多笔记分享
[外链图片转存中…(img-ms6TYEwi-1714990699270)]
890
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
