最新因为一次 Kafka 宕机，我明白了 Kafka 高可用原理！，面试java对未来的规划

总结

三个工作日收到了offer，头条面试体验还是很棒的，这次的头条面试好像每面技术都问了我算法，然后就是中间件、MySQL、Redis、Kafka、网络等等。

• 第一个是算法

关于算法，我觉得最好的是刷题，作死的刷的，多做多练习，加上自己的理解，还是比较容易拿下的。

而且，我貌似是将《算法刷题LeetCode中文版》、《算法的乐趣》大概都过了一遍，尤其是这本

《算法刷题LeetCode中文版》总共有15个章节：编程技巧、线性表、字符串、栈和队列、树、排序、查找、暴力枚举法、广度优先搜索、深度优先搜索、分治法、贪心法、动态规划、图、细节实现题

《算法的乐趣》共有23个章节：

• 第二个是Redis、MySQL、kafka（给大家看下我都有哪些复习笔记）

基本上都是面试真题解析、笔记和学习大纲图，感觉复习也就需要这些吧（个人意见）

• 第三个是网络（给大家看一本我之前得到的《JAVA核心知识整理》包括30个章节分类，这本283页的JAVA核心知识整理还是很不错的，一次性总结了30个分享的大知识点）

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

要解决这个问题，就要从Kafka的高可用实现开始讲起。

Kafka的多副本冗余设计

=================

不管是传统的基于关系型数据库设计的系统，还是分布式的如 zookeeper 、Redis 、 Kafka 、 HDFS等等，实现高可用的办法通常是采用冗余设计，通过冗余来解决节点宕机不可用问题。首先简单了解Kafka的几个概念：

物理模型

逻辑模型

Broker （节点）：Kafka服务节点，简单来说一个 Broker 就是一台Kafka服务器，一个物理节点。

Topic （主题）：在Kafka中消息以主题为单位进行归类，每个主题都有一个 Topic Name ，生产者根据Topic Name将消息发送到特定的Topic，消费者则同样根据Topic Name从对应的Topic进行消费。

Partition （分区）：Topic （主题）是消息归类的一个单位，但每一个主题还能再细分为一个或多个 Partition （分区），一个分区只能属于一个主题。主题和分区都是逻辑上的概念，举个例子，消息1和消息2都发送到主题1，它们可能进入同一个分区也可能进入不同的分区（所以同一个主题下的不同分区包含的消息是不同的），之后便会发送到分区对应的Broker节点上。

Offset （偏移量）：分区可以看作是一个只进不出的队列（Kafka只保证一个分区内的消息是有序的），消息会往这个队列的尾部追加，每个消息进入分区后都会有一个偏移量，标识该消息在该分区中的位置，消费者要消费该消息就是通过偏移量来识别。

其实，根据上述的几个概念，是不是也多少猜到了Kafka的多副本冗余设计实现了？别急，咱继续往下看。

在Kafka 0.8版本以前，是没有多副本冗余机制的，一旦一个节点挂掉，那么这个节点上的所有 Partition的数据就无法再被消费。这就等于发送到Topic的有一部分数据丢失了。

在0.8版本后引入副本记者则很好地解决宕机后数据丢失的问题。副本是以 Topic 中每个 Partition的数据为单位，每个Partition的数据会同步到其他物理节点上，形成多个副本。

每个 Partition 的副本都包括一个 Leader 副本和多个 Follower副本，Leader由所有的副本共同选举得出，其他副本则都为Follower副本。在生产者写或者消费者读的时候，都只会与Leader打交道，在写入数据后Follower就会来拉取数据进行数据同步。

就这么简单？是的，基于上面这张多副本架构图就实现了Kafka的高可用。当某个 Broker 挂掉了，甭担心，这个 Broker 上的 Partition 在其他 Broker 节点上还有副本。你说如果挂掉的是 Leader 怎么办？那就在 Follower中在选举出一个 Leader 即可，生产者和消费者又可以和新的 Leader 愉快地玩耍了，这就是高可用。

你可能还有疑问，那要多少个副本才算够用？Follower和Leader之间没有完全同步怎么办？一个节点宕机后Leader的选举规则是什么？

直接抛结论:

多少个副本才算够用？

副本肯定越多越能保证Kafka的高可用，但越多的副本意味着网络、磁盘资源的消耗更多，性能会有所下降，通常来说副本数为3即可保证高可用，极端情况下将 replication-factor 参数调大即可。

Follower和Lead之间没有完全同步怎么办？

Follower和Leader之间并不是完全同步，但也不是完全异步，而是采用一种 ISR机制（ In-Sync Replica）。每个Leader会动态维护一个ISR列表，该列表里存储的是和Leader基本同步的Follower。如果有Follower由于网络、GC等原因而没有向Leader发起拉取数据请求，此时Follower相对于Leader是不同步的，则会被踢出ISR列表。所以说，ISR列表中的Follower都是跟得上Leader的副本。

一个节点宕机后Leader的选举规则是什么？

分布式相关的选举规则有很多，像Zookeeper的 Zab 、 Raft 、 Viewstamped Replication 、微软的 PacificA 等。而Kafka的Leader选举思路很简单，基于我们上述提到的 ISR列表，当宕机后会从所有副本中顺序查找，如果查找到的副本在ISR列表中，则当选为Leader。另外还要保证前任Leader已经是退位状态了，否则会出现脑裂情况（有两个Leader）。怎么保证？Kafka通过设置了一个controller来保证只有一个Leader。

Ack参数决定了可靠程度

另外，这里补充一个面试考Kafka高可用必备知识点：request.required.asks 参数。

Asks这个参数是生产者客户端的重要配置，发送消息的时候就可设置这个参数。该参数有三个值可配置：0、1、All 。

第一种是设为0

意思是生产者把消息发送出去之后，之后这消息是死是活咱就不管了，有那么点发后即忘的意思，说出去的话就不负责了。不负责自然这消息就有可能丢失，那就把可用性也丢失了。

第二种是设为1

意思是生产者把消息发送出去之后，这消息只要顺利传达给了Leader，其他Follower有没有同步就无所谓了。存在一种情况，Leader刚收到了消息，Follower还没来得及同步Broker就宕机了，但生产者已经认为消息发送成功了，那么此时消息就丢失了。注意，

设为1是Kafka的默认配置

最后总结我的面试经验

2021年的金三银四一眨眼就到了，对于很多人来说是跳槽的好机会，大厂面试远没有我们想的那么困难，摆好心态，做好准备，你也可以的。

另外，面试中遇到不会的问题不妨尝试讲讲自己的思路，因为有些问题不是考察我们的编程能力，而是逻辑思维表达能力；最后平时要进行自我分析与评价，做好职业规划，不断摸索，提高自己的编程能力和抽象思维能力。

BAT面试经验

实战系列：Spring全家桶+Redis等

其他相关的电子书：源码+调优

面试真题：

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**

需要这份系统化的资料的朋友，可以点击这里获取