刷java面试题的app，Java开发者必看

面试官最爱问的Kakfa，基础+进阶+高级，疯狂轰炸！

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的 站中的所有动作流数据。 这种动作( 页浏览，搜索和其他用户的行动)是在现代 络上的许多 会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

而这几年，大数据发展迅猛，Kakfa 凭借高可靠、高吞吐、高可用、可伸缩几大特性，成为数据管道技术的首选，也成了面试官的最爱。

XA 协议大概的两个流程为：

1. 第一阶段（prepare）：事务管理器向所有本地资源管理器发起请求，询问是否是 ready 状态，所有参与者都将本事务能否成功的信息反馈发给协调者；
2. 第二阶段 (commit/rollback)：事务管理器根据所有本地资源管理器的反馈，通知所有本地资源管理器，步调一致地在所有分支上提交或者回滚。

XA 协议是如何满足 ACID 的呢p>

原子性和持久性我们就不用说，我们看看隔离性和一致性。

隔离性

XA 协议中没有描述如何实现分布式事务的隔离性，但是 XA 协议要求每个资源管理器都要实现本地事务，也就是说基于 XA 协议实现的分布式事务的隔离性是由每个资源管理器本地事务的隔离性来保证的，当一个分布式事务的所有子事务都是隔离的，那么这个分布式事务天然的就实现了隔离性。

一致性

在单机环境下的一致性就是保证当前服务器数据一致即可。事务执行完毕数据最终一致，不同的隔离级别下事务执行过程的中间状态不能被别的事务观察到。

事务执行完毕最终一致这个好保证，但是在RR 隔离级别下不可见一个未提交事务的中间态在分布式情况该如何做到呢上 MySQL 提供了MVCC机制，采用多版本控制来处理，那分布式事务场景也是否也可以提供这样的机制呢 协议并没有定义怎么实现全局的快照，一个基本思路是用一个集中式或者逻辑上单调递增的东西来控制生成全局 Snapshot，每个事务或者每条 SQL 执行时都去获取一次，从而实现不同隔离级别下的一致性。当然开发的难度还是挺大。

存在的问题：

• 同步阻塞：当参与事务者存在占用公共资源的情况，其中一个占用了资源，其他事务参与者就只能阻塞等待资源释放，处于阻塞状态。

• 单点故障：一旦事务管理器出现故障，整个系统不可用。

• 数据不一致：在阶段二，如果事务管理器只发送了部分 commit 消息，此时 络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

• 不确定性：当事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

总体来说 XA 方案实现简单，但是带来的问题如果放在数据一致性要求严格的场景是无法保证数据正确性的。另外事务管理器单点会带来隐患，同步阻塞模型也致使并发能力弱。

TCC

关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。 TCC 事务机制相比于上面介绍的 XA，解决了其几个缺点：

1. 解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。
2. 同步阻塞：引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。
3. 数据一致性，有了补偿机制之后，由业务活动管理器控制一致性。

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC 模型完全交由业务实现，每个子业务都需要实现 Try-Confirm-Cancel 三个接口，对业务侵入大，资源锁定交由业务方。

• Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）。
• Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。
• Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源 Cancel 操作满足幂等性 Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

事务发起方在处理完业务逻辑之后需要将当前事务保存在消息表中，之后将消息发送到消息中间件中，并将消息的状态设置为 “发送中”。

如果消息在投递过程中丢失怎么办呢发起方可以设置一个定时任务主动扫描状态为 “发送中” 的消息重新投送。只有消息被业务方消费完毕返回消费成功的结果才确认成功并将消息状态改为“已发送”。

这里因为 络异常或者发送异常导致一个消息可能会被重复发送，所以要求接收方要做到幂等性，允许重复消费。

这种方案的好处就是方案简单，成本较低，实现也不复杂。

但是坏处也有很多，比如通过消息的方式延迟不好控制；本地消息表与业务耦合在一起没有做到通用性；本地消息表基于数据库来实现，有一定的瓶颈。

事务消息

上面说的本地消息表的模式无法支持本地事务执行和消息发送一致性的问题，如果能在本地事务执行和发消息这两个操作上加上事务，那岂不是完美。

基于这个思路， 在 MQ 中存储消息的状态才是真理，消息生产者先把消息发送给MQ，此时消息状态为“待确认”，接着生产者去执行本地事务，如果执行成功就给MQ发送消息让他更改消息状态为 “待发送”并发送消息，如果执行失败则删除消息。

这样就保证了本地事务和消息发送一致性问题。

XA 模式

XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案，任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。

XA 协议有一系列的指令，分别对应一阶段和二阶段操作。“xa start” 和 “xa end” 用于开启和结束XA 事务；“xa prepare” 用于预提交 XA 事务，对应一阶段准备；“xa commit”和“xa rollback”用于提交、回滚 XA 事务，对应二阶段提交和回滚。

在 XA 模式下，每一个 XA 事务都是一个事务参与者。分布式事务开启之后，首先在一阶段执行“xa start”、“业务 SQL”、“xa end”和 “xa prepare” 完成 XA 事务的执行和预提交；二阶段如果提交的话就执行 “xa commit”，如果是回滚则执行“xa rollback”。这样便能保证所有 XA 事务都提交或者都回滚。

• 一阶段：

在 XA 模式的一阶段，Seata 会拦截“业务 SQL”，在“业务 SQL”之前开启 XA 事务（“xa start”），然后执行“业务 SQL”，结束 XA 事务“xa end”，最后预提交 XA 事务（“xa prepare”），这样便完成 “业务 SQL”的准备操作。

• 二阶段提交：

执行“xa commit”指令，提交 XA 事务，此时“业务 SQL”才算真正的提交至数据库。

• 二阶段回滚：

执行“xa rollback”指令，回滚 XA 事务，完成“业务 SQL”回滚，释放数据库锁资源。

XA 模式下，用户只需关注“业务 SQL”，Seata 会自动生成一阶段、二阶段提交和二阶段回滚操作。XA 模式和 AT 模式一样是一种对业务无侵入性的解决方案；但与 AT 模式不同的是，XA 模式将快照数据和行锁等通过 XA 指令委托给了数据库来完成，这样 XA 模式实现更加轻量化。

AT 模式

AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

TCC 三个方法描述：

• Try：资源的检测和预留；
• Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；
• Cancel：预留资源释放。

用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。

Saga 模式

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

最后，附一张自己面试前准备的脑图：

• Spring全家桶（实战系列）

很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。

资料领取方式：Java全套学习手册

然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。

以下是我私藏的面试题库：

[外链图片转存中…(img-5iDZlI1D-1622099091201)]

很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。

资料领取方式：Java全套学习手册

以上学习资料均免费分享，最后祝愿各位身体健康，顺利拿到心仪的offer！

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92487 人正在系统学习中