📑前言

本文主要是关于kafka消息队列的文章⛺️

🎬作者简介：大家好，我是青衿🥇
☁️博客首页：CSDN主页放风讲故事
🌄每日一句：努力一点，优秀一点

目录

---

kafka面试题

1、kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么好处？

Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从broker 拉取消息。

2、kafka判断一个节点还活着的有那两个条件？

（1）节点必须维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
（2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久

3、讲一讲 kafka 的 ack 的三种机制

request.required.acks 有三个值 0 1 -1(all)，具体如下：

• 0：生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。
• 1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
• -1(all)：服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack，这样数据不会丢失。

4.kafka 如何保证消息幂等性

这个问题换种问法，就是kafka如何保证消息的幂等性。对于消息队列来说，出现重复消息的概率还是挺大的，不能完全依赖消息队列，而是应该在业务层进行数据的一致性幂等校验。

比如你处理的数据要写库（mysql，redis等），你先根据主键查一下，如果这数据都有了，你就别插入了，进行一些消息登记或者update等其他操作。另外，数据库层面也可以设置唯一健，确保数据不要重复插入等 。一般这里要求生产者在发送消息的时候，携带全局的唯一id。

5.发送消息的分区策略有哪些？

• 1.轮询：依次将消息发送该topic下的所有分区，如果在创建消息的时候 key 为 null，Kafka 默认采用这种策略。
• 2.key 指定分区：在创建消息是 key 不为空，并且使用默认分区器，Kafka 会将 key 进行 hash，然后根据hash值映射到指定的分区上。这样的好处是 key 相同的消息会在一个分区下，Kafka 并不能保证全局有序，但是在每个分区下的消息是有序的，按照顺序存储，按照顺序消费。在保证同一个 key 的消息是有序的，这样基本能满足消息的顺序性的需求。但是如果 partation 数量发生变化，那就很难保证 key 与分区之间的映射关系了。
• 3.自定义策略：实现 Partitioner 接口就能自定义分区策略。
• 4.指定 Partiton 发送

6. kafka消费完 数据删除吗

1.基于时间或者文件大小 某种策略批量删除

7.队列模型了解吗？Kafka 的消息模型知道吗？

队列模型：P2P、Pub/Sub
Kafka 采用的是 Pub/Sub 模型

8.Kafka 如何保证消息不重复消费？

kafka出现消息重复消费的原因：

服务端侧已经消费的数据没有成功提交 offset（根本原因）。
Kafka 侧 由于服务端处理业务时间长或者网络链接等等原因让 Kafka 认为服务假死，触发了分区 rebalance。
解决方案：

消费消息服务做幂等校验，比如 Redis 的set、MySQL 的主键等天然的幂等功能。这种方法最有效。

将 enable.auto.commit 参数设置为 false，关闭自动提交，开发者在代码中手动提交 offset。那么这里会有个问题：什么时候提交offset合适？

9.Kafka如何处理大量积压消息

方法：
1 增大partion数量，
2 消费者加了并发，服务， 扩大消费线程
3 增加消费组服务数量
4 kafka单机升级成了集群
5 避免消费者消费消息时间过长，导致超时
6 使Kafka分区之间的数据均匀分布

场景：
1 如果是Kafka消费能力不足，则可以考虑增加 topic 的 partition 的个数，
同时提升消费者组的消费者数量，消费数 = 分区数 （二者缺一不可）

2 若是下游数据处理不及时，则提高每批次拉取的数量。批次拉取数量过少
（拉取数据/处理时间 < 生产速度），使处理的数据小于生产的数据，也会造成数据积压。

10.顺序消息 消费失败问题

解决方案：重试表

顺序消息消费时，可以先查询订单是否在重试表有记录，如果有记录，则记录到重试表

消费失败时，也可以加到重试表中

📑文章末尾