kafka介绍（二）_kafka producer timeout-优快云博客

本文链接：https://blog.youkuaiyun.com/dongdongdongJL/article/details/128041375

Kafka是一个分布式流处理平台，本文深入探讨了其消费者和生产者的工作机制，消息存储的文件方式，以及核心API。重点分析了消息丢失的三个阶段，提出解决方案，如acks机制、ISR和AR机制。此外，讨论了如何保证消息顺序、防止数据重复以及处理消息堆积的方法。最后，对比了Kafka与其他MQ、API和邮件系统的差异，展示了其在大数据处理中的高效性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

费者可能会陷入循环中，一直返回空数据。针对这一点， Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费， consumer 会等待一段时间之后再返回，这段时长即为 timeout。

轮训

那么消费者是如何知道生产者发送了数据呢？换一句话来说就是，消费者什么时候 pull 数据呢？其实生产者产生的数据消费者是不知道的，KafkaConsumer 采用轮询的方式定期去 Kafka Broker 中进行数据的检索，如果有数据就用来消费，如果没有就再继续轮询等待

消息存储的方式

kafka存储的数据采用的文件存储，并且是在后边不断地追加保证数据的读写顺序。

7.0 核心API

四个核心的API

Producer API，它允许应用程序向一个或多个 topics 上发送消息记录

Consumer API，允许应用程序订阅一个或多个 topics 并处理为其生成的记录流

Streams API，它允许应用程序作为流处理器，从一个或多个主题中消费输入流并为其生成输出流，有效的将输入流转换为输出流。

Connector API，它允许构建和运行将 Kafka 主题连接到现有应用程序或数据系统的可用生产者和消费者。例如，关系数据库的连接器可能会捕获对表的所有更改

8.0 消息丢失分析

一般而言，消息丢失的三个阶段：

生产消息

如果出现了网络不可用、消息本身不合格等原因导致消息根本没有被 Broker 接收，那就相当于消息在生产者端就消失了。

存储消息

Broker 端的消息丢失，一般是由 Broker 服务不可用造成的，例如 Broker 都宕机了导致消息丢失

消费消息

消费者在消费消息的过程中，会同时更新消费者位移，也就是「已经消费到哪一条消息了」。这里就存在一个问题，当消费一个消息的时候，是先处理消息，成功后再更新位移，还是先更新位移，再处理消息。

如果先更新位移，在处理消息，当消息处理出现问题，或者更新完位移、消息还未处理，消费者出现宕机等问题的时候，消息就会丢失。

而如果先处理消息再更新位移，虽然可能会出现重复消费同一个消息的问题，但是，我们可以通过消费者处理逻辑实现幂等的方式来解决。

解决方案：

producer 生产消息

ack 机制

生产者 acks参数指定了必须要有多少个分区副本收到消息，生产者才认为该消息是写入成功的，这个参数对于消息是否丢失起着重要作用。

ack 策略

现在我们已经知道生产者发送消息有个确认的机制，那么Kafka里是何时确认呢？Kafka是通过配置acks的值确认机制的，这里一共提供了三种策略，对应不同的ACK机制：

acks=0，生产者不等待broker的响应。这种情况下延迟最低，但是有可能丢失数据，比较适合高吞吐量、接受消息丢失的场景。

acks=1，生产者发送消息等待broker的响应，等待leader落盘成功后响应确认。这种情况下，如果是在leader完成同步消息给follower前发生故障，则可能发生消息丢失。

acks=-1，生产者发送消息等待broker的响应，直到leader和follower全部落盘成功后才会响应确认。此机制能严格保证不丢失数据。但当所有的follower同步完成之后，leader发送ack响应之前，leader发生了宕机，此时生产者会以为发送失败了，然后会重新发送数据给新的leader，因此该情况下会导致数据重复发送。

broker存储消息

存储消息阶段需要在消息刷盘之后再给生产者响应，假设消息写入缓存中就返回响应，那么机器突然断电这消息就没了，而生产者以为已经发送成功了。

如果Broker是集群部署，有多副本机制，即消息不仅仅要写入当前,还需要写入副本机中。那配置成至少写入两台机子后再给生产者响应。这样基本上就能保证存储的可靠了。所以broker 消息存储主要是靠的是冗余副本，即多个Replica。

ISR机制和 AR机制

简单来说，分区中的所有副本统称为 AR (Assigned Replicas)。所有与leader副本保持一定程度同步的副本（包括leader副本在内）组成 ISR (In Sync Replicas)。 ISR 集合是 AR 集合的一个子集。消息会先发送到leader副本，然后follower副本才能从leader中拉取消息进行同步。同步期间，follow副本相对于leader副本而言会有一定程度的滞后。前面所说的 ”一定程度同步“ 是指可忍受的滞后范围，这个范围可以通过参数进行配置。于leader副本同步滞后过多的副本（不包括leader副本）将组成 OSR （Out-of-Sync Replied）由此可见，AR = ISR + OSR。正常情况下，所有的follower副本都应该与leader 副本保持