Kafka 面试拷问 20 题

Kafka 面试拷问 20 题

1. Kafka 基础

1. 架构图

2. Kafka 名词：

• Producer：消息生产者，就是向 kafka broker 发消息的客户端。
• Consumer：消息消费者，向 kafka broker 取消息的客户端。
• Topic：可以理解为一个队列，一个 Topic 又分为一个或多个分区。
• Consumer Group：这是 kafka 用来实现一个 topic 消息的广播（发给所有的 consumer）和单播（发给任意一个 consumer）的手段。一个 topic 可以有多个 Consumer Group。
• Broker：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
• Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker上，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的id（offset）。将消息发给 consumer，kafka 只保证按一个 partition 中的消息的顺序，不保证一个 topic 的整体（多个 partition 间）的顺序。
• Offset：kafka 的存储文件都是按照 offset.kafka 来命名，用 offset 做名字的好处是方便查找。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。

2. Kafka 数据重复怎么解决

• 幂等性+ack=-1+事务
• Kafka数据重复，可以再下一级：SparkStreaming、redis或者hive中dwd层去重，去重的手段：分组、按照id开窗只取第一个值；

3. Kafka 如何不丢失数据

1.producer

• 使用带回调的 send
• acks=-1，含义是 producer 会等 ISR 中所有副本都写入成功才返回
• 设置 retries 为一个较大的值

2.Broker

• 设置 unclean.leader.election.enable = false，ISR 为空时产生 unclean 选举
• 设置 replication.factor >= 3。多保存几份数据
• 设置 min.insync.replicas > 1。这依然是 Broker 端参数，控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。与 acks不同，它保证的写入副本的下限
• 设置 replication.factor = min.insync.replicas + 1

4. Kafka 数据积压怎么解决

• 如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）
• 如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。
• 如果是当天重要的活动，可以将其他不重要的业务暂停，减少数据量

5. Kafka 的幂等和事务对比

幂等是会话内，单个分区不重复
事务时全局唯一，但是性能消耗高

1. Kafka 幂等性
Producer的幂等性指的是当发送同一条消息时，数据在Server端只会被持久化一次，数据不丟不重，但是这里的幂等性是有条件的：
1）只能保证Producer在单个会话内不丟不重，如果Producer出现意外挂掉再重启是无法保证的（幂等性情况下，是无法获取之前的状态信息，因此是无法做到跨会话级别的不丢不重）。
2）幂等性不能跨多个Topic-Partition，只能保证单个Partition内的幂等性，当涉及多个 Topic-Partition时，这中间的状态并没有同步。

2. Kafka事务
Kafka从0.11版本开始引入了事务支持。事务可以保证Kafka在Exactly Once语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。
1）Producer事务
为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID。
为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator。Producer就是通过和Transaction Coordinator交互获得Transaction ID对应的任务状态。Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。
2）Consumer事务
上述事务机制主要是从Producer方面考虑，对于Consumer而言，事务的保证就会相对较弱，尤其时无法保证Commit的信息被精确消费。这是由于Consumer可以通过offset访问任意信息，而且不同的Segment File生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

6. Kafka 常用的调优参数

1. Broker参数配置（server.properties）

1、网络和io操作线程配置优化
# broker处理消息的最大线程数（默认为3）
num.network.threads=cpu核数+1
# broker处理磁盘IO的线程数 
num.io.threads=cpu核数*2

2、log数据文件刷盘策略 
# 每当producer写入10000条消息时，刷数据到磁盘 
log.flush.interval.messages=10000
# 每间隔1秒钟时间，刷数据到磁盘
log.flush.interval.ms=1000

3、日志保留策略配置
# 保留三天，也可以更短 （log.cleaner.delete.retention.ms）
log.retention.hours=72

4、副本相关配置
offsets.topic.replication.factor:3
# 这个参数指新创建一个topic时，默认的Replica数量,Replica过少会影响数据的可用性，太多则会白白浪费存储资源，一般建议在2~3为宜

2. Producer优化（producer.properties）

buffer.memory:33554432 (32m)
#在Producer端用来存放尚未发送出去的Message的缓冲区大小。缓冲区满了之后可以选择阻塞发送或抛出异常，由block.on.buffer.full的配置来决定。

compression.type:none
#默认发送不进行压缩，推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。

3. Consumer优化

num.consumer.fetchers:1
#启动Consumer的个数，适当增加可以提高并发度。

fetch.min.bytes:1
#每次Fetch Request至少要拿到多少字节的数据才可以返回。

fetch.wait.max.ms:100
#在Fetch Request获取的数据至少达到fetch.min.bytes之前，允许等待的最大时长。对应上面说到的Purgatory中请求的超时时间。

4. Kafka内存调整（kafka-server-start.sh）
默认内存1个G，生产环境尽量不要超过6个G。
export KAFKA_HEAP_OPTS="-Xms4g -Xmx4g"

7. 如果 leader crash时，ISR为空怎么办?

如果开启了 unclean.leader.election.enable 会进行 Unclean 领导选举，但是会导致消息不一致。如果关闭，会一直等旧leader恢复

8. 机器资源评估

每日 10 亿数据，8亿数据会在2小时涌入，则高峰期 5.9 w/s。高峰期 QPS 保持总 QPS 的 30%，则总 QPS 为 20万
1 台 kafka 物理机能支持 4 万 QPS，所以需要 5 台物理机

9. Kafka 进行监控的工具

• Kafka Manager：应该算是最有名的专属 Kafka 监控框架了，是独立的监控系统。
• Kafka Monitor：LinkedIn 开源的免费框架，支持对集群进行系统测试，并实时监控测试结果。
• CruiseControl：也是 LinkedIn 公司开源的监控框架，用于实时监测资源使用率，以及提供常用运维操作等。无 UI 界面，只提供 REST API。JMX 监控：由于 Kafka 提供的监控指标都是基于 JMX 的，因此，市面上任何能够集成 JMX 的框架都可以使用，比如 Zabbix 和 Prometheus。
• 已有大数据平台自己的监控体系：像 Cloudera 提供的 CDH 这类大数据平台，天然就提供 Kafka 监控方案。
• JMXTool：社区提供的命令行工具，能够实时监控 JMX 指标。答上这一条，属于绝对的加分项，因为知道的人很少，而且会给人一种你对 Kafka 工具非常熟悉的感觉。如果你暂时不了解它的用法，可以在命令行以无参数方式执行一下kafka-run-class.sh kafka.tools.JmxTool，学习下它的用法。

10. 哪些场景你会选择Kafka？

• 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种 consumer，例如hadoop、HBase、Solr等。
• 消息系统：解耦和生产者和消费者、缓存消息等。
• 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动， 这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析， 或者装载到hadoop、数据仓库中做离线分析和挖掘。
• 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
• 流式处理：比如spark streaming和 Flink

11. 如何实现 Kafka 全局有序

• 只设置一个分区
• 自定义分区器。类似于桶排序，分区有序，分区内部有序，则全局有序

12. 监控 Kafka 的框架都有哪些？

• Kafka Manager：应该算是最有名的专属 Kafka 监控框架了，是独立的监控系统。
• Kafka Monitor：LinkedIn 开源的免费框架，支持对集群进行系统测试，并实时监控测试结果。
• CruiseControl：也是 LinkedIn 公司开源的监控框架，用于实时监测资源使用率，以及提供常用运维操作等。无 UI 界面，只提供 REST API。
• JMX 监控：由于 Kafka 提供的监控指标都是基于 JMX 的，因此，市面上任何能够集成 JMX 的框架都可以使用，比如 Zabbix 和 Prometheus。
• 已有大数据平台自己的监控体系：像 Cloudera 提供的 CDH 这类大数据平台，天然就提供 Kafka 监控方案。
• JMXTool：社区提供的命令行工具，能够实时监控 JMX 指标。答上这一条，属于绝对的加分项，因为知道的人很少，而且会给人一种你对 Kafka 工具非常熟悉的感觉。如果你暂时不了解它的用法，可以在命令行以无参数方式执行一下kafka-run-class.sh kafka.tools.JmxTool，学习下它的用法。

13. Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？

1. 分区器:根据键值确定消息应该处于哪个分区中，默认情况下使用轮询分区，可以自行实现分区器接口自定 义分区逻辑

2. 序列化器:键序列化器和值序列化器，将键和值都转为二进制流 还有反序列化器 将二进制流转为指定类 型数据

3. 拦截器：两个方法 doSend()方法会在序列化之前完成 onAcknowledgement()方法在消息确认或失败 时调用 可以添加多个拦截器按顺序执行

调用顺序: 拦截器doSend() -> 序列化器 -> 分区器

14. Kafka 分区的目的

对于集群的好处是，实现负载均衡
对于消费者的好处是，增加并发量，提高效率

默认策略是轮循，如果指定了 key，想同的 key 会放入到相同的区， 即会按消息键保序

15. Kafka 为什么不支持读写分离？

自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离，也就是说，Follower 副本能够对外提供读服务。之前的版本不支持读写分离是因为：

• 场景不适用。读写分离适用于那种读负载很大，而写操作相对不频繁的场景，可 Kafka 不属于这样的场景。
• 同步机制。Kafka 采用 PULL 方式实现 Follower 的同步，因此，Follower 与 Leader 存在不一致性窗口。如果允许读 Follower 副本，就势必要处理消息滞后（Lagging）的问题。

16. 说说Kafka的ISR副本同步队列

ISR 是表示用来记录有哪些副本和 Leader 副本保持同步的， Leader 副本默认就在里面。当副本和 Leader 副本同步时间超过 replica.lag.time.max.ms 就会被踢出 ISR，反之会被加入。如果Leader进程挂掉，会在ISR队列中选择一个服务作为新的Leader

17. Kafka 的高水位（High Watermark）有什么作用

在 Kafka 中，高水位的作用主要有 2 个。

• 定义消息可见性，即用来标识分区下的哪些消息是可以被消费者消费的。
• 帮助 Kafka 完成副本同步

高水位 HW 和日志末端位移 LEO 是副本对象的两个重要属性：

• LEO 是记录本副本磁盘写入情况
• HW 是记录副本的同步情况

对于副本而言：

• Leader 副本中，LEO 是指从 Producer 发来的数据写入到磁盘的位移，HW 是指所有副本LEO 的最小值。
• Follower 副本中，LEO 是指从 Leader 读取的数据写入到磁盘的位移，HW 是当前 LEO 值和 Leader 的 HW 的较小值。

18. 简述 Follower 副本消息同步的完整流程

首先，Follower 发送 FETCH 请求给 Leader。接着，Leader 会读取底层日志文件中的消息数据，再更新它内存中的 Follower 副本的 LEO 值，更新为 FETCH 请求中的 fetchOffset 值。最后，尝试更新分区高水位值。Follower 接收到 FETCH 响应之后，会把消息写入到底层日志，接着更新 LEO 和 HW 值

19. Kafka 实现分区消息顺序性的原理

TODO

20. Kafka为什么读写效率高

写：

• 内存池设计
• 默认200ms批量发送一次数据，同一个 broker 的请求会合并成一个
• Reactor 网络设计模式（selector ，网络线程池，IO线程池）
• 顺序写磁盘
• 零拷贝

读：

• 跳表设计，找到文件
• 日志存储是稀疏索引，找到数据