问你为什么选择Kafka,你会怎么回答?

简介: 可靠的含义在百度百科的解释是:可以信赖、可以相信、可靠的朋友。那Kafka究竟是不是一个可靠的朋友呢?既然全世界绝大部分高可用系统都有Kafka的支持,Kafka必定有其过人之处,跟着我来分析分析。另外多提一嘴Kafka在GitHub目前已有star数27.6k、fork数13.6k。本文收录在我开源的《Java学习面试指南》中,一份覆盖Java程序员所需掌握的Java核心知识、面试重点。希望收到大家的 ⭐ Star ⭐支持。,相信你看了一定不会后悔。

可靠的含义在百度百科的解释是:可以信赖、可以相信、可靠的朋友。那Kafka究竟是不是一个可靠的朋友呢?既然全世界绝大部分高可用系统都有Kafka的支持,Kafka必定有其过人之处,跟着我来分析分析。

另外多提一嘴Kafka在GitHub目前已有star数27.6k、fork数13.6k。

在可靠的人手中,有强人在关照

在可靠的人手中,有强人在关照

本文收录在我开源的《Java学习面试指南》中,一份覆盖Java程序员所需掌握的Java核心知识、面试重点。希望收到大家的 ⭐ Star ⭐支持。GitHub地址:https://github.com/hdgaadd/JavaGetOffer,相信你看了一定不会后悔。

1. Kafka高水位

面试官:知道Kafka高水位吗?

我们都知道Kafka消息保存在首领分区和分区副本中,Kafka要保证即使从分区副本读取消息也只会读取已提交的消息。Kafka的高水位就是为了这个目标而开发出来的。

如果大家对消息已提交的概念不清楚的话,可以看下以下的解释。

Kafka的消息只有在所有分区副本都同步该消息后,才算是已提交的消息

在分区复制的过程中,首领分区会在发送的数据里加入当前高水位。当前高水位就是复制偏移量,记录了当前已提交消息的最大偏移量。而分区副本就可以根据首领分区副本提供的高水位,来避免未提交的消息被消费者消费。

就如下图,最大偏移量的限制就像海面上的水位。

在这里插入图片描述

2. Kafka消息可靠性

2.1 消息存储可靠性

面试官:你说说Kafka是怎么保证消息可靠性的?

大家在回答面试官问题前可以思考下,可靠性的含义是什么?

在业务系统中,消息的不丢失是最重要的,数据即是金钱。如果把客户的一条支付消息丢失,而这条支付信息的涉及的金额不菲,想想对公司的损失有多大。所以可靠性意味着对消息的存储和保护。

Kafka在这方面采用了复制机制和分区多副本架构来作为消息可靠性的核心。

(1)分区多副本架构。

Kafka的所有主题被分为了多个分区存储在多个Broker里,而每个分区可以有多个副本。例如有4个Broker节点,Broker1存储了分区首领副本,而Broker2、Broker3可以存储其分区副本。

Kafka对消息的存储有多个分区副本来支持,可以避免单点问题导致数据丢失找不回来的情况。

(2)复制机制。

在通常情况下消费者都是从首领副本里读取消息,同时会有n(复制系数)个Broker机器会去同步复制首领副本后,生成跟随者副本也就是分区副本。

如果首领副本的机器挂了,分区副本就会选举成为新的首领副本

复制机制保证了分区副本和首领副本的数据一致性,有复制机制的加持,分区多副本架构才是可用的。

2.2 生产者消费者可靠性

面试官:还有呢?

上面所说的其实是基于Broker层面带给Kafka的可靠性保障,我们还需要在生产者、消费者层面下功夫,来使整个系统减少丢失数据的风险。

一、在生产者方面。

Kafka提供了多种发送确认模式,我们可以根据业务的可靠性需求配置合适的acks。

  1. ack = 0。如果消息生产者能够把消息通过网络发送出去,则认为消息已成功写入。
  2. ack = 1。如果首领分区收到消息并成功写入,生产者收到确认返回,则认为消息已成功写入。
  3. ack = all。只有在消息成功写入所有分区副本后,才认为消息已成功写入。这保证了消息的多备份。

以上的各种acks情况如果失败的话,我们可以让生产者继续重试发送消息,直到Kafka返回成功。

二、在消费者方面

大家如果能回答上文第一个面试官问题:知道Kafka高水位吗,就知道Kafka高水位保证了消费者只会读取到已提交的数据,即被写入所有分区副本的数据。所以消费者要确保的是跟踪哪些数据已读取了、哪些数据未读取。

  1. 消费者消费消息时会先获取一批消息,同时从最后一个偏移量开始读取,这保证了消息的顺序性
  2. 消费者消费消息后会同步提交、异步提交偏移量,保证了消息不被其他消费者重复消费

2.3 消费堆积问题

面试官:那要是Kafka消费堆积了你怎么处理?

这个问题是面试官常考的一个问题,我们要从Broker和消费者两方面来看。

一、Broker的话。

  1. 每个topic是分为多个分区给不同Broker进行处理,要合理分配分区数量来提高Broker的消息处理能力。比如3个Broker2个分区,可以改为3个Broker3个分区。
  2. 可以横向扩展Broker集群,来提高Broker的消息处理能力。

二、消费者的话。

  1. 可以增加消费者服务数量来提高消息消费能力。
  2. 在提交偏移量时,可以把同步提交改为异步提交。异步提交无需等待Kafka的确认返回,减少了同步等待Broker的时间。

3. Kafka控制器

面试官:知道Kafka控制器吧?

Kafka控制器其实也是一个Broker,不过它还负责选举分区首领。Kafka的控制器和Redis集群的哨兵的选举功能是一样的。

也就是在首领副本所在的分区失效后,Kafka会通过控制器来在分区副本里选举出新的首领副本

创作不易,不妨点赞、收藏、关注支持一下,各位的支持就是我创作的最大动力❤️

相关文章
|
6月前
|
消息中间件 运维 Kafka
|
6月前
|
消息中间件 SQL 数据处理
Flink报错问题之flink消费rabbitmq报错如何解决
Flink报错通常是指在使用Apache Flink进行实时数据处理时遇到的错误和异常情况;本合集致力于收集Flink运行中的报错信息和解决策略,以便开发者及时排查和修复问题,优化Flink作业的稳定性。
|
6月前
|
消息中间件 存储 Kafka
kafka常见问题处理
kafka常见问题处理
105 1
|
消息中间件 数据采集 存储
Kafka常见问题总结
会不会丢消息? Offset 怎么保存? Consumer 重复消费问题怎么处理? 如何保证消息的顺序? 数据倾斜怎么处理? 一个 Topic 分配多少个 Partiton 合适以及修改 Partiton有哪些限制?
|
6月前
|
消息中间件 缓存 关系型数据库
探究Kafka原理-1.初识Kafka
探究Kafka原理-1.初识Kafka
70 0
|
消息中间件 存储 缓存
Kafka 常见问题
唯一可能导致消费者弄丢数据的情况,就是消费到了这个消息,然后还没处理就自动提交了offset,让kafka以为你已经消费好了这个消息。 对于消费端来说只要关闭自动提交offset,在处理完之后自己手动提交offset,就可以保证数据不会丢。但是此时确实还是会重复消费,比如你刚处理完,还没提交offset,结果自己挂了,此时肯定会重复消费一次,自己保证幂等性就好了。
59 0
|
消息中间件 存储 缓存
聊聊 Kafka: Kafka 为啥这么快?
聊聊 Kafka: Kafka 为啥这么快?
|
消息中间件 存储 缓存
聊聊 Kafka:Kafka 消息重复的场景以及最佳实践
聊聊 Kafka:Kafka 消息重复的场景以及最佳实践
473 0
|
消息中间件 存储 负载均衡
【Kafka从入门到放弃系列 零】Kafka看这一篇就够了(一)
【Kafka从入门到放弃系列 零】Kafka看这一篇就够了
288 0
|
消息中间件 存储 缓存
【Kafka从入门到放弃系列 零】Kafka看这一篇就够了(二)
【Kafka从入门到放弃系列 零】Kafka看这一篇就够了
229 0