成绩要从一次Kafka的宕机末尾说起。

笔者所在的是一家金融科技公司，但公司外部并没有采用在金融支付范围更为盛行的 RabbitMQ ，而是采用了设计之初就为日志处置而生的 Kafka ，所以我不断很猎奇Kafka的高可用完成和保障。从 Kafka 部署后，系统外部运用的 Kafka 不断运转波动，没有出现不可用的状况。

但最近系统测试人员常反应偶有Kafka消费者收不到音讯的状况，登陆管理界面发现三个节点中有一个节点宕机挂掉了。但是按照高可用的理念，三个节点还有两个节点可用怎样就惹起了整个集群的消费者都接纳不到音讯呢？

要处置这个成绩，就要从 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 的高可用。当某个 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的默许配置，可见Kafka的默许配置也不是那么高可用，而是对高可用和高吞吐量做了权衡折中。

第三种是设为All（或许-1）

意思是消费者把音讯发送出去之后，不只Leader要接纳到，ISR列表中的Follower也要同步到，消费者才会义务音讯发送成功。

进一步思索， Asks=All 就不会出现丧失音讯的状况吗？答案能否。当ISR列表只剩Leader的状况下， Asks=All 相当于 Asks=1 ，这种状况下假设节点宕机了，还能保证数据不丧失吗？因此只要在 Asks=All 并且有ISR中有两个正本的状况下才能保证数据不丧失。

处置成绩

绕了一大圈，了解了Kafka的高可用机制，终于回到我们一末尾的成绩本身， Kafka 的一个节点宕机后为什么不可用？

我在开发测试环境配置的 Broker 节点数是3， Topic 是正本数为3， Partition 数为6， Asks 参数为1。

(责任编辑：admin)