总结
虽然面试套路众多，但对于技术面试来说，主要还是考察一个人的技术能力和沟通能力。不同类型的面试官根据自身的理解问的问题也不尽相同，没有规律可循。
上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料
有些面试官喜欢问自己擅长的问题，比如在实际编程中遇到的或者他自己一直在琢磨的这方面的问题，还有些面试官，尤其是大厂的比如 BAT 的面试官喜欢问面试者认为自己擅长的，然后通过提问的方式深挖细节，刨根到底。
分布式事务在分布式环境下，为了满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论（BASE 相关理论，涉及内容非常多，感兴趣的同学，可以参考 BASE 理论）：
基本业务可用性（Basic Availability）柔性状态（Soft state）最终一致性（Eventual consistency）同样的，分布式事务也部分遵循 ACID 规范：
原子性：严格遵循一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽持久性：严格遵循
◆ 分布式事务的解决方案
◆ 两阶段提交/XA
XA 是由 X/Open 组织提出的分布式事务的规范，XA 规范主要定义了(全局)事务管理器™和(局部)资源管理器(RM)之间的接口。本地的数据库如 mysql 在 XA 中扮演的是 RM 角色
XA 一共分为两阶段：
第一阶段（prepare）：即所有的参与者 RM 准备执行事务并锁住需要的资源。参与者 ready 时，向 TM 报告已准备就绪。第二阶段 (commit/rollback)：当事务管理者™确认所有参与者(RM)都 ready 后，向所有参与者发送 commit 命令。目前主流的数据库基本都支持 XA 事务，包括 mysql、oracle、sqlserver、postgre
XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。
把上面的转账作为例子，一个成功完成的 XA 事务时序图如下：
如果有任何一个参与者 prepare 失败，那么 TM 会通知所有完成 prepare 的参与者进行回滚。
XA 事务的特点是：
-
简单易理解，开发较容易
-
对资源进行了长时间的锁定，并发度低
如果读者想要进一步研究 XA，go 语言可参考 DTM，java 语言可参考 seata
◆ SAGA
Saga 是这一篇数据库论文 saga 提到的一个方案。其核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
把上面的转账作为例子，一个成功完成的 SAGA 事务时序图如下：
SAGA 事务的特点：
-
并发度高，不用像 XA 事务那样长期锁定资源
-
需要定义正常操作以及补偿操作，开发量比 XA 大
-
一致性较弱，对于转账，可能发生 A 用户已扣款，最后转账又失败的情况
论文里面的 SAGA 内容较多，包括两种恢复策略，包括分支事务并发执行，我们这里的讨论，仅包括最简单的 SAGA
SAGA 适用的场景较多，长事务适用，对中间结果不敏感的业务场景适用
如果读者想要进一步研究 SAGA，go 语言可参考 DTM，java 语言可参考 seata
◆ TCC
关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
TCC 分为 3 个阶段
-
Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
-
Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，Confirm 失败后需要进行重试。
-
Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。
把上面的转账作为例子，通常会在 Try 里面冻结金额，但不扣款，Confirm 里面扣款，Cancel 里面解冻金额，一个成功完成的 TCC 事务时序图如下：
TCC 特点如下：
-
并发度较高，无长期资源锁定。
-
开发量较大，需要提供 Try/Confirm/Cancel 接口。
-
一致性较好，不会发生 SAGA 已扣款最后又转账失败的情况
-
TCC 适用于订单类业务，对中间状态有约束的业务
如果读者想要进一步研究 TCC，go 语言可参考 DTM，java 语言可参考 seata
◆ 本地消息表
本地消息表这个方案最初是 ebay 架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章。设计核心是将需要分布式处理的任务通过消息的方式来异步确保执行。
大致流程如下：
写本地消息和业务操作放在一个事务里，保证了业务和发消息的原子性，要么他们全都成功，要么全都失败。
容错机制：
-
扣减余额事务 失败时，事务直接回滚，无后续步骤
-
轮序生产消息失败， 增加余额事务失败都会进行重试
本地消息表的特点：
-
长事务仅需要分拆成多个任务，使用简单
-
生产者需要额外的创建消息表
-
每个本地消息表都需要进行轮询
-
消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作
适用于可异步执行的业务，且后续操作无需回滚的业务
◆ 事务消息
在上述的本地消息表方案中，生产者需要额外创建消息表，还需要对本地消息表进行轮询，业务负担较重。阿里开源的 RocketMQ 4.3 之后的版本正式支持事务消息，该事务消息本质上是把本地消息表放到 RocketMQ 上，解决生产端的消息发送与本地事务执行的原子性问题。
事务消息发送及提交：
-
发送消息（half 消息）
-
服务端存储消息，并响应消息的写入结果
-
根据发送结果执行本地事务（如果写入失败，此时 half 消息对业务不可见，本地逻辑不执行）
-
根据本地事务状态执行 Commit 或者 Rollback（Commit 操作发布消息，消息对消费者可见）
正常发送的流程图如下：
补偿流程：
对没有 Commit/Rollback 的事务消息（pending 状态的消息），从服务端发起一次“回查”Producer 收到回查消息，返回消息对应的本地事务的状态，为 Commit 或者 Rollback 事务消息方案与本地消息表机制非常类似，区别主要在于原先相关的本地表操作替换成了一个反查接口
事务消息特点如下：
-
长事务仅需要分拆成多个任务，并提供一个反查接口，使用简单
-
消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作
适用于可异步执行的业务，且后续操作无需回滚的业务
如果读者想要进一步研究事务消息，可参考 rocketmq，为了方便大家学习事务消息，DTM 也提供了简单实现
◆ 最大努力通知
发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：
有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。前面介绍的的本地消息表和事务消息都属于可靠消息，与这里介绍的最大努力通知有什么不同？
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
解决方案上，最大努力通知需要：
-
提供接口，让接受通知放能够通过接口查询业务处理结果
-
消息队列 ACK 机制，消息队列按照间隔 1min、5min、10min、30min、1h、2h、5h、10h 的方式，逐步拉大通知间隔 ，直到达到通知要求的时间窗口上限。之后不再通知
最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口
技术学习总结
学习技术一定要制定一个明确的学习路线，这样才能高效的学习，不必要做无效功，既浪费时间又得不到什么效率，大家不妨按照我这份路线来学习。
最后面试分享
大家不妨直接在牛客和力扣上多刷题，同时，我也拿了一些面试题跟大家分享，也是从一些大佬那里获得的，大家不妨多刷刷题，为金九银十冲一波！
大家不妨直接在牛客和力扣上多刷题，同时，我也拿了一些面试题跟大家分享，也是从一些大佬那里获得的，大家不妨多刷刷题，为金九银十冲一波！
[外链图片转存中…(img-m5lNNzVi-1715663142957)]
[外链图片转存中…(img-ak5P5OBL-1715663142957)]
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
