消息中间件-kafka

1.kafka如何保证消息不丢失

使用Kafka在消息的收发过程都会出现消息丢失，Kafka分别给出了解决方案

• 生产者发送消息到Broker丢失

• 消息在Broker中存储丢失

• 消费者从Broker接收消息丢失

生产者发送消息到Broker丢失

同步发送一般会产生阻塞，使用异步发送

• 设置异步发送

//同步发送
RecordMetadata recordMetadata = kafkaProducer.send(record).get();
//异步发送
kafkaProducer.send(record, new Callback() {
    @Override
    public void onCompletion(RecordMetadata recordMetadata, Exception e) {
        if (e != null) {
        	System.out.println("消息发送失败|记录日志”);
        }
        long offset = recordMetadata.offset();
        int partition = recordMetadata.partition();
        String topic = recordMetadata.topic();
    }
});

• 消息重试

//设置重试次数
prop.put(ProducerConfig.RETRIES_CONFIG,10);

消息在Broker中存储丢失

• 发送确认机制acks

  确认机制	说明
  acks = 0	生产者在成功写入消息之前不会等待任何来自服务器的响应，消息有丢失的风险，但是速度最快
  acks = 1（默认值）	只要集群首领节点收到消息，生产者就会收到一个来自服务器的成功响应
  acks = all	只有当所有参与赋值的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应（性能最低）

消费者从Broker接收消息丢失

• Kafka 中的分区机制指的是将每个主题划分成多个分区(Partition)

• topic分区中消息只能由消费者组中的唯一一个消费者处理，不同的分区分配给不同的消费者(同一个消费者组)

先异步再同步提交：

• Kafka是如何保证消息不丢失？

需要从三个层面去解决这个问题：

• 生产者发送消息到Broker丢失

  • 设置异步发送,发送失败使用回调进行记录或重发
  • 失败重试,参数配置,可以设置重试次数

• 消息在Broker中存储丢失

  • 发送确认acks,选择all,让所有的副本都参与保存数据后确认

• 消费者从Broker接收消息丢失

  • 关闭自动提交偏移量,开启手动提交偏移量

  • 提交方式,最好是同步+异步提交

• Kafka中消息的重复消费问题如何解决的？

• 关闭自动提交偏移量,开启手动提交偏移量

• 提交方式,最好是同步+异步提交

• 幂等方案

2.kafka是如何保证消费的顺序性

应用场景:

• 即时消息中的单对单聊天和群聊,保证发送方消息发送顺序与接收方的顺序一致

• 充值转账两个渠道在同一个时间进行余额变更,短信通知必须要有顺序

​

topic分区中消息只能由消费者组中的唯一一个消费者处理，所以消息肯定是按照先后顺序进行处理的。但是它也仅仅是保证Topic的一个分区顺序处理，不能保证跨分区的消息先后处理顺序。所以，如果你想要顺序的处理Topic的所有消息，那就只提供一个分区。

//指定分区
kafkaTemplate.send( topic: "springboot-kafka-topic",partition: 0, key: "key-001", data: "value-0001");
//相同的业务key (就可以映射到同一个分区)
kafkaTemplate.send( topic: "springboot-kafka-topic", key:"key-04", data: "value-0001");

• Kafka是如何保证消费的顺序性

问题原因：一个topic的数据可能存储在不同的分区中，每个分区都有一个按照顺序的存储的偏移量，如果消费者关联了多个分区不能保证顺序性

解决方案:

• 发送消息时指定分区号
• 发送消息时按照相同的业务设置相同的key

3.kafka的高可用机制

集群模式

• Kafka 的服务器端由被称为Broker的服务进程构成，即一个Kafka集群由多个Broker组成

• 这样如果集群中某一台机器宕机，其他机器上的Broker也依然能够对外提供服务。这其实就是Kafka提供高可用的手段之一

分区备份机制

• 一个topic有多个分区,每个分区有多个副本,其中有一个leader,其余的是follower,副本存储在不同的broker中
• 所有的分区副本的内容是都是相同的,如果leader发生故障时,会自动将其中一个follower提升为leader

ISR(in-sync replica) 需要同步复制保存的follower

如果leader失效后,，要选出新的leader。选举的原则如下:

1. 选举时优先从ISR中选定，因为这个列表中follower的数据是与leader同步的

2. 如果ISR列表中的follower都不行了，就只能从其他follower中选取

//一个topic默认分区的replication个数,不能大于集群中broker的个数。默认为1
default.replication.factor=3
//最小的ISR副本个数
min.insync.replicas=2

• kafka的高可用机制有了解过吗？

  可以从两个层面回答，第一个是集群，第二个是复制机制

  • 集群:

    • 一个kafka集群由多个broker实例组成,即使某一台宕机,也不耽误其他broker继续对外提供服务

  • 复制机制:

    • 一个topic有多个分区,每个分区有多个副本,有一个leader,其余的是follower,副本存储在不同的broker中

    • 所有的分区副本的内容是都是相同的,如果leader发生故障时,会自动将其中一个follower提升为leader，保证了系统的容错性、高可用性

• 解释一下复制机制中的ISR

  ISR (in-sync replica)需要同步复制保存的follower

  分区副本分为了两类，一个是ISR，与leader副本同步保存数据；另外一个普通的副本，是异步同步数据，当leader挂掉之后，会优先从ISR副本列表中选取一个作为leader

4.kafka数据清理机制

kafka文件存储机制

存储结构：

为什么要分段?

• 删除无用文件方便，提高磁盘利用率（不用在一个文件中筛选）

• 查找数据便捷（文件以偏移量命名）

数据清理机制

1. 根据消息的保留时间,当消息在kafka中保存的时间超过了指定的时间,就会触发清理过程

# The minimum age of a log file to be eligible for deletion due to age
log.retention.hours=168(默认七天)

2. 根据topic存储的数据大小,当topic所占的日志文件大小大于一定的阈值,则开始删除最久的消息。需手动开启

# A size-based retention policy for logs. Segments are pruned from the log unless the remaining
# segments drop below log.retention. bytes. Functions independently of log.retention.hours.
#log.retention.bytes=1073741824

• Kafka数据清理机制了解过嘛

• Kafka存储结构

  • Kafka中topic的数据存储在分区上,分区如果文件过大会分段存储segment
  • 每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储
  • 分段的好处是,第一能够减少单个文件内容的大小,查找数据方便,第二方便kafka进行日志清理。

• 日志的清理策略有两个:

  • 根据消息的保留时间，当消息保存的时间超过了指定的时间，就会触发清理,默认是168小时(7天)

  • 根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。(默认关闭)

5.kafka中实现高性能的设计有了解过吗

• 消息分区：不受单台服务器的限制，可以不受限的处理更多的数据

• 顺序读写：磁盘顺序读写，提升读写效率

• 页缓存：把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问

• 零拷贝：减少上下文切换及数据拷贝

• 消息压缩：减少磁盘IO和网络IO

• 分批发送：将消息打包批量发送，减少网络开销

零拷贝

开始4次拷贝：

两次拷贝：（零拷贝指的是cpu零拷贝，也就是用户态和内核态的切换）

6.Kafka 的 Exactly Once 和数据库事务有什么区别？

结论一句话（直接背）

Kafka 的 Exactly Once 是“消息处理语义”，而数据库事务是“数据一致性语义”，两者解决的问题不同。

---

1️⃣ 关注点不同（核心区别）

对比项	Kafka Exactly Once	数据库事务
关注对象	消息处理结果	数据状态
解决问题	消息是否被“生效一次”	数据是否一致
范围	Kafka 内（Kafka → Kafka）	单数据库
核心机制	幂等 + 事务 + offset	ACID

👉 Kafka 管的是：
“这条消息算不算成功处理过？”

👉 数据库管的是：
“这次数据修改是不是一个整体？”

---

2️⃣ Kafka Exactly Once 的“事务”≠数据库事务（面试加分点）

Kafka 事务：

• 只保证：
  • 写消息 + 提交 offset 的原子性
• 不保证：
  • 跨系统（如 DB、Redis）的一致性

数据库事务：

• 保证 ACID
• 只能在数据库内部

👉 Kafka 事务不能替代数据库事务

---

面试回答模板（推荐）

Kafka 的 Exactly Once 语义主要保证消息在 Kafka 内部的处理结果只生效一次，而数据库事务关注的是数据修改的一致性。Kafka 的事务只能保证消息写入和 offset 提交的原子性，无法覆盖外部系统，因此不能等同于数据库事务。

---

7.为什么 Exactly Once 只在「分区级别」保证？

结论一句话（直接背）

因为 Kafka 的顺序、offset 和事务边界都是以 partition 为最小单位的。

---

1️⃣ Kafka 的三大“分区级事实”

① 消息顺序只在 partition 内保证

② offset 是 partition 级别的

③ 事务状态是按 partition 维护的

---

2️⃣ 一个关键事实（面试官爱听）

Kafka 没有跨 partition 的全局顺序，也没有跨 partition 的原子提交能力。

如果跨 partition 保证 Exactly Once：

• 需要：
  • 分布式事务
  • 全局锁
  • 两阶段提交

👉 性能和复杂度不可接受

---

3️⃣ 所以 Kafka 的设计取舍是：

牺牲全局 Exactly Once
换取高吞吐 + 高可用

---

面试标准回答

Kafka 的 Exactly Once 是在分区级别保证的，因为消息顺序、offset 以及事务状态都依赖于 partition。Kafka 并不提供跨分区的全局事务能力，因此无法保证多分区之间的 Exactly Once。

8.如果写数据库，Kafka 怎么保证不重复？

结论先给你（重点）

Kafka 本身无法保证“写数据库不重复”，必须靠业务侧或数据库侧实现幂等。

这是一个送分但很多人答错的问题。

---

1️⃣ 为什么 Kafka 保证不了？

• Kafka 的 Exactly Once：
  • 只覆盖 Kafka 内部
• 数据库：
  • 是 Kafka 之外的系统

👉 Kafka 事务管不到数据库

---

2️⃣ 正确做法一：数据库幂等（最推荐）

常见方式：

① 唯一键 / 唯一索引（最稳）

order_id UNIQUE

重复插入直接失败。

---

② 状态机更新

UPDATE order
SET status = 'PAID'
WHERE order_id = ? AND status = 'CREATED'

---

3️⃣ 正确做法二：去重表 / 消费表

consume_log(message_id, status)

• 插入成功 → 执行业务
• 插入失败 → 直接跳过

---

4️⃣ 正确做法三：事务 + offset 提交配合（有限）

DB 事务提交成功
→ 再提交 Kafka offset

⚠️ 仍然可能重复，只是降低概率

---

5️⃣ 错误但常见的回答（别踩）

❌ “用 Kafka Exactly Once 就不会写重复数据库”
❌ “Kafka 事务可以保证 DB 一致性”

---

面试标准回答（直接用）

Kafka 的 Exactly Once 无法覆盖数据库写操作，因此在写数据库场景下必须通过幂等设计来避免重复处理，例如使用唯一索引、状态机更新或去重表。Kafka 的事务只能保证 Kafka 内部消息和 offset 的原子性。