Apache Kafka 是一个分布式流处理平台。它起初由 LinkedIn 开发，并在 2011 年成为 Apache 项目的顶级项目。它以高吞吐量、低延迟、可扩展性和持久性著称，广泛应用于实时数据管道、流处理、日志聚合和事件驱动架构中。以下是 Kafka 的详细解析：
一、Kafka基础架构
1.Producer（生产者）
数据的发布者，负责向 Kafka 的 Topic发送消息。
支持异步/同步发送、批量提交和配置消息分区策略。
2.Consumer（消费者）
数据的接收者，订阅Topic并消费消息。
3.Consumer Group（消费者组）
消费者的逻辑集合，每个消费者组内的消费者共享主题的分区以并行处理消息。
每个分区只能由同一个消费者组内的一个消费者处理，确保消息的顺序处理和负载均衡。
4.Broker（代理）
Kafka集群中的单个节点，负责处理请求、存储和处理消息。
每个 Broker 可管理多个 Topic 的分区。
5.Topic（主题）
消息的逻辑分类。
6.Partition（分区）
每个Topic可以分成一个或多个分区，按策略在一个Broker或多个Broker之间分布。
每个分区是有序、不可变的消息序列，每条新消息都会按顺序添加到分区的末尾。
每条消息在分区内通过 Offset（偏移量） 唯一标识。
7.Replication（副本）
每个分区有多个副本（Leader + Followers）。
（1）Leader（主副本）
每个分区多副本的主角色，负责处理读写请求。
生产者发送数据的接收对象，以及消费者消费数据的对象都是Leader。
（2）Follower（从副本）
每个分区多副本的从角色，负责异步复制数据。
实时的从Leader中同步数据，保持和Leader数据的同步，Leader发生故障的时候，选举某个Follower会成为新的Leader。
8.Offset
分区中的每条消息都会被附加一个唯一标识符：偏移量（offset）。
每个分区中的偏移量始终单调递增。
消费者可以通过偏移量来指定读取的位置。
9.ISR（同步副本集）
与 Leader 保持同步的副本集合，Leader 从 ISR 中选举，负责故障转移。
10.ZooKeeper或 KRaft
旧版本 Kafka 依赖 ZooKeeper 管理集群元数据和状态信息。
新版本 Kafka（3.0+）支持 KRaft 模式，通过内置的 Raft 协议替代 ZooKeeper。
二、Kafka工作机制
1. 生产者发送流程
（1）序列化
将消息 Key/Value 序列化为字节流。
（2）分区选择
默认轮询或按 Key 的 Hash 值选择 Partition。
可自定义 Partitioner 接口实现特定路由逻辑。
（3）发送到 Leader
将消息发送到 Partition 的 Leader 副本。
（4）ACK 确认
acks=0：不等待确认，可能丢失消息。
acks=1：Leader 写入后确认，可能丢失未同步副本的数据。
acks=all：所有 ISR 副本写入后确认（最高可靠性）。
（5）配置示例
| Properties props = new Properties(); // broker服务器 props.put("bootstrap.servers", "broker1:9092,broker2:9092"); // 最高可靠性 props.put("acks", "all"); // 重试次数 props.put("retries", 3); // 序列化 props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); Producer<String, String> producer = new KafkaProducer<>(props); |
2.消费者消费流程
（1）订阅 Topic
消费者或消费者组组订阅一个或多个 Topic。
（2）分区分配
组协调器（Coordinator）分配 Partition 给消费者（如 Range 或 RoundRobin 策略）。
（3）拉取消息
消费者从分配的 Partition 拉取消息（poll() 方法）。
（4）处理与提交 Offset
自动提交：定期提交 Offset，可能导致重复消费。
手动提交：处理完成后调用 commitSync() 或 commitAsync()。
（5）配置示例：
| Properties props = new Properties(); props.put("bootstrap.servers", "broker1:9092,broker2:9092"); // 消费者组 props.put("group.id", "order-consumers"); // 关闭自动提交 props.put("enable.auto.commit", "false"); props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); Consumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(Collections.singletonList("orders")); |
3. 副本同步与 Leader 选举
（1）ISR 机制
Leader 维护 ISR 列表，仅包含与 Leader 同步的副本 Follower 。
若 Follower 副本落后 Leader 超过 replica.lag.time.max.ms，则被移出 ISR。
（2）Leader 选举
当 Leader 宕机时，Controller（通过 ZooKeeper 或 KRaft 选举）从 ISR 中选择新 Leader。
若 ISR 为空且 unclean.leader.election.enable=true，允许非 ISR 副本成为 Leader（可能丢数据）。
三、Kafka生产者
生产者是消息的发布者，负责向 Kafka 的 Topic发送消息。
支持异步/同步发送、批量提交和配置消息分区策略。
1.生产者ACK机制
（1）ACK机制
当生产者发送消息到 Kafka时，通过ACK来确认消息是否被成功接收。
（2）ACK级别
acks=0：生产者在发送消息后不等待服务器的确认。
acks=1：生产者会等待 Leader 主副本确认消息已写入其本地日志。
acks=all（或 acks=-1）：生产者会等待 ISR中的所有副本都成功写入消息后，才会收到确认。
（3）影响因素
acks 设置直接影响了生产者发送消息的延迟和可靠性。
生产者可以在发送每条消息时单独设置 acks 级别，以灵活应对不同的需求。
较小的acks值：可以提高生产者的吞吐量，但可能会增加消息丢失的风险；
较大的acks值：可以减少消息丢失的可能性，但会增加延迟。
（4）使用选择
对于需要高吞吐量的场景，选择较低的acks级别。
对消息传递的实时性低和数据完整性要求较高的场景，选择较高的acks级别。
2.生产者分区分配策略
（1）轮询或哈希值
默认轮询或按 Key 的 Hash 值选择 Partition。
（2）Partitioner 接口
可自定义 Partitioner 接口实现特定路由逻辑。
四、Kafka消费者
1.消费者消费模式
（1）单消费者模式
在单消费者模式下，一个消费者实例订阅了一个或多个主题的所有分区。
该模式下，每个分区只会由一个消费者实例进行消费，适用于不需要水平扩展的情况。
（2）消费者组模式
每个消费者组可以包含多个消费者实例，每个消费者实例订阅一个或多个主题的一个或多个分区。
Kafka 会确保每个分区只能由消费者组中的一个消费者实例消费，确保每条消息只被消费一次。
该模式支持水平扩展和并行处理，适用于大多数生产环境中需要高吞吐量和容错性的情况。
（3）广播消费模式
每个消费者实例订阅了同一个主题的所有分区，并且每个实例都会收到主题中的所有消息副本。
这种模式适用于需要多个消费者实例独立处理每个消息副本的场景，比如日志分析、实时处理等。
2.消费者分区分配策略
（1）Range（默认策略）
Range表示为每个消费者分配连续的分区范围。
具体步骤：
a.计算分区范围：
首先，根据主题的分区数量和消费者群组的成员数量计算出每个消费者应分配的分区数量。
b.分配连续范围：
将分区按顺序排序，并依次将连续的分区范围分配给每个消费者，确保每个消费者都获得连续的一段分区。
（2）Round Robin
Round Robin将主题的分区列表按顺序排序，再按照消费者列表的顺序，依次将每个分区分配给各个消费者。
（3）自定义分配策略
通过实现Kafka的 ConsumerPartitionAssignor 接口来实现自定义的分区分配策略。
（4）切换策略
通过设置 partition.assignment.strategy 参数来选择使用的分配策略。
3.消费者消息偏移量的存储位置
在 Kafka 的消费者配置中，可以通过 group.id 参数来指定消费者群组的标识，Kafka 会根据这个标识来管理消费者的偏移量信息。消费者在消费消息时，会定期地将当前的 offset 提交给 Kafka，Kafka 将这些 offset 存储到 __consumer_offsets 主题中。
（1）Kafka 的内置主题
Kafka 0.8 之后引入的内置 __consumer_offsets 主题，用于存储消费者群组的偏移量信息。
特点：
集中管理：所有消费者群组的偏移量信息都集中存储在 Kafka 集群中，便于管理和维护。
容错性：内置的 __consumer_offsets 主题会自动复制到多个 Kafka 节点上，保证了消费者 offset 的可靠性和容错能力。
高可用性：通过 Kafka 的副本机制，可以保证即使某个节点故障，消费者 offset 的信息依然可用。
（2）外部存储
ZooKeeper：
在Kafka 0.8之前，消费者 offset 是存储在 ZooKeeper 中的。目前 Kafka 不再推荐使用 ZooKeeper 存储 offset，而是推荐使用内置主题。
外部数据库(MySQL、Redis)：
特殊需求下，可选择将 offset 存储在外部数据库中，但需要自行处理数据的一致性和容错性。
4.消费者消息偏移量提交策略
消费者可以选择同步或异步地将偏移量提交给 Kafka。
同步提交可以保证偏移量的可靠性，但可能会影响消费的性能。
异步提交则可以提高消费性能，但可能会带来一定的数据丢失风险。
四、Kafka分区
每个Topic可以分成一个或多个分区，分区在 Broker之间分布。
每个分区是有序、不可变的消息序列，每条新消息都会按顺序添加到分区的末尾。
每条消息在分区内通过 Offset（偏移量） 唯一标识。
1.分区策略
（1）默认
使用轮询（Round-robin）的方式选择分区，即依次将消息发送到每个分区。
（2）key分区
根据消息的 key，计算 key 的哈希值，并基于哈希值选择一个分区。
（3）自定义分区
自定义分区需要实现 Kafka 的 Partitioner 接口，重写 partition 方法来定义分区的逻辑。
这种方式允许根据消息的其他属性或者外部条件来决定消息发送的目标分区。
2.如何选择分区策略
（1）顺序性要求
如果要保证具有相同 key 的消息被发送到同一个分区，实现顺序性，可选择按照key分区策略。
（2）负载均衡
如果希望将消息均匀地分布到所有分区，可以考虑默认轮询分区策略，或者自定义一个基于业务逻辑的分区策略。
（3）自定义需求
如果有特定的业务逻辑或者消息属性需要决定消息发送到哪个分区，可以实现自定义分区策略来满足需求。
五、Kafka副本同步
1.Leader和Follower
Kafka每个分区都有一个leader主副本和多个follower从副本。
leader负责读写操作，将消息写入本地日志中。
follower负责同步leade中的数据，发生故障时被选举上升为新leader。
2.ISR
ISR（In-Sync Replica）包含了与leader保持同步的从副本集合。
只有在 ISR 中的副本才能够参与读写请求的处理。
（1）ISR设置
可以通过调整配置参数，如：min.insync.replicas，来动态地设置需要保持同步的最小副本数，以确保数据的可靠复制和读写请求的处理能力。
（2）动态调整
如果一个副本落后于 leader 副本太多，它可能会被从 ISR 中移除，直到追赶上来重新加入。
滞后判断：可以通过配置：replica.lag.time.max.ms ，来判断follower是否滞后。
故障移除：当follower故障，Kafka 会自动从 ISR中移除该副本。
（3）故障转移
当leader发生故障，Kafka会从 ISR 中选择一个新的副本作为新的 Leader。
3.LEO和HW
（1）LEO(Log End Offset)
LEO表示当前分区中最新的消息的偏移量（offset），即分区中消息日志中最新消息的位置。
LEO随着消息不断追加到分区中而增加。
（2）HW(High Watermark)
HW表示当前分区的复制进度。已经被所有ISR成功复制的消息的偏移量HW 的位置总是小于或等于 LEO。只有达到 HW 的消息才可以被消费者消费。
消费者消费消息时，只能消费到HW之前的消息，从而保证消费的消息是已经被所有同步副本接收的，确保了数据的持久性和一致性。
3.主副本同步的过程
（1）生产者
生产者写入消息时，会将消息追加到分区的日志末尾，并更新 LEO。
然后根据ACK配置，等待ISR操作的执行及HW的更新。
（2）消费者
消费者消费消息时，会根据 HW 确定可以读取的最大偏移量，以避免读取未被完全复制的消息。
消费者还可以通过监视 LEO 和 HW 的变化来调整消费策略，例如重新分配分区或重新连接。
4.同步延迟和性能
（1）同步延迟
副本之间的同步延迟受网络延迟、硬件性能和负载等因素影响。较长的同步延迟可能会影响整体的系统性能和吞吐量。
（2）性能
Kafka通过异步的消息传输和ISR的机制来最大程度地提高性能，并且在可能的情况下，保持所有 ISR 中的副本尽可能快地同步。
六、Kafka消息存储机制
Kafka 使用高效的日志文件存储数据，通过将数据写入磁盘来提供持久化存储，并支持高吞吐量的数据写入。
每个分区对应一个日志文件，消息按照时间顺序追加写入该文件，每条消息通过 Offset唯一标识。消息存储是按时间或大小来设置保留策略的，消息可以根据配置自动过期删除。
1.日志文件
每个分区在物理上对应于一个日志文件（Log file）。
每个分区的每个副本（Replica）都对应独立的日志文件（Log file）。
日志文件存储在 Kafka 的数据目录（data directory）中。
日志文件由两部分组成：消息集（Message Set）和索引（Index）。
（1）消息集
消息集包含实际的消息数据，按照追加方式写入，不支持消息的修改或删除。
（2）索引
索引包含每条消息的Offset和位置，用于快速定位消息。
2.日志段和日志段滚动
（1）日志段（Log Segment）
日志文件（Log file）按照日志段来管理。
日志段有固定的大小（可配置，默认为1GB），当日志段达到设定的大小时会发生日志段滚动。
（2）日志段滚动（Log Segment Rolling）
当一个日志段达到预设大小时，Kafka 将停止向该日志段追加新消息，并创建一个新的日志段来接收新的消息。旧的日志段将被标记为不可变（immutable），不再接收新消息。
3.清理策略
为了避免无限增长的数据存储，Kafka 实现了不同的清理策略：
（1）日志段压缩
Kafka支持在后台对日志段进行压缩，删除重复的消息，减少存储空间的使用。
（2）日志段删除
基于保留策略，Kafka 可以自动删除过期的日志段，释放磁盘空间。
4.持久化策略
（1）保留策略
时间保留：retention.ms（默认 7 天）。
大小保留：retention.bytes（按 Partition 总大小）。
（2）日志压缩（Log Compaction）
保留每个 Key 的最新值，适用于状态更新场景。
八、Kafka配置
1.生产者配置
（1）配置示例
| // 设置Kafka集群的地址 String bootstrapServers = "kafka1:9092,kafka2:9092"; // 创建生产者的配置对象 Properties props = new Properties(); props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers); // 所有ISR副本都应答后才认为消息提交成功，默认为"all" props.put(ProducerConfig.ACKS_CONFIG, "all"); // 重试次数 props.put(ProducerConfig.RETRIES_CONFIG, 3); // 批处理大小，一次发送的批量数据大小 props.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384); // 等待时间，控制批处理的时间窗口大小 props.put(ProducerConfig.LINGER_MS_CONFIG, 1); // 控制未确认请求的最大数量 props.put(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, 5); // 键的序列化器 props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()); // 值的序列化器 props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()); // 创建Kafka生产者实例 KafkaProducer<String, String> producer = new KafkaProducer<>(props); // 创建消息并发送到指定的主题 String topic = "my-topic"; String key = "my-key"; String value = "Hello, Kafka!"; producer.send(new ProducerRecord<>(topic, key, value)); // 关闭生产者实例 producer.close(); |
（2）配置解析
| 1.BOOTSTRAP_SERVERS_CONFIG: Kafka集群的地址，指定一个或多个broker的地址，用逗号分隔。 2.ACKS_CONFIG: 指定生产者要求leader收到的确认消息数。 "all"表示需要ISR中的所有副本都确认消息。默认为"1"，表示只需leader确认。 3.RETRIES_CONFIG: 生产者在发生可重试异常时的重试次数。默认为0，即不重试。 4.BATCH_SIZE_CONFIG: 控制单个批次发送消息的大小。当未达到此大小时，生产者会等待更多消息积累进来。 5.LINGER_MS_CONFIG: 设置生产者在发送批次之前等待更多消息的时间。这可以减少请求的数量，但可能增加延迟。 6.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION: 控制未确认请求的最大数量。这可以帮助确保在网络故障时不会有太多的请求积压。 7.KEY_SERIALIZER_CLASS_CONFIG: 键的序列化器类，这里使用的是String类型作为键，因此使用了StringSerializer类。 8.VALUE_SERIALIZER_CLASS_CONFIG: 值的序列化器类，这里同样使用String作为值的序列化器。 |
2.消费者配置
（1）配置示例
| // 设置Kafka集群的地址 String bootstrapServers = "kafka1:9092,kafka2:9092"; // 设置消费者组ID String groupId = "my-group"; // 创建消费者的配置对象 Properties props = new Properties(); props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers); // 消费者组信息 props.put(ConsumerConfig.GROUP_ID_CONFIG, groupId); // 开启offset自动提交，默认为true props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true"); // 自动提交偏移量的时间间隔 props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000"); // 从最早的偏移量开始消费 props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest"); // 键的反序列化器 props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName()); // 值的反序列化器 props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,StringDeserializer.class.getName()); // 创建Kafka消费者实例 KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); // 订阅主题 String topic = "my-topic"; consumer.subscribe(Collections.singletonList(topic)); // 消费消息 while (true) { // 拉取消息的超时时间 var records = consumer.poll(Duration.ofMillis(100)); for (var record : records) { System.out.printf( "Received message: key = %s, value = %s, partition = %d, offset = %d%n", record.key(), record.value(), record.partition(), record.offset()); } } |
（2）配置解析
| 1.BOOTSTRAP_SERVERS_CONFIG: Kafka集群的地址，指定一个或多个broker的地址，用逗号分隔。 2.GROUP_ID_CONFIG: 消费者组ID，用于标识属于同一个消费者组的消费者。 3.ENABLE_AUTO_COMMIT_CONFIG: 是否开启自动提交偏移量。默认为true。如果开启，消费者会定期自动提交当前消费的偏移量。 4.AUTO_COMMIT_INTERVAL_MS_CONFIG: 自动提交偏移量的时间间隔。默认为5000毫秒。 5.AUTO_OFFSET_RESET_CONFIG: 指定消费者在找不到初始偏移量或偏移量无效的情况下如何处理。"earliest"表示从最早的偏移量开始消费，"latest"表示从最新的偏移量开始消费。 6.KEY_DESERIALIZER_CLASS_CONFIG: 键的反序列化器类，这里使用的是String类型作为键，因此使用了StringDeserializer类。 7.VALUE_DESERIALIZER_CLASS_CONFIG: 值的反序列化器类，这里同样使用String作为值的反序列化器。 8.poll()方法: 用于拉取消息的超时时间。如果没有消息可供消费，该方法将阻塞指定的毫秒数，直到超时或收到消息为止。 |
九、Kafka事务
用于在Kafka中执行具有原子性、一致性、隔离性和持久性（ACID）特性的一组操作的机制。用于确保生产者和消费者之间的数据传输过程中的数据完整性和可靠性。
1.Kafka事务实现步骤
（1）生产者事务
开启事务：beginTransaction()；
发送消息：send()；
提交事务：commitTransaction()；
中止回滚事务：abortTransaction()；
（2）消费者事务
消费者通常不直接参与事务的提交或回滚，但可以通过消费者组的方式确保在事务内消费消息时的一致性。
2.Kafka事务使用场景
（1）Exactly-Once语义
对于一些需要确保消息不丢失且不重复处理的场景，Kafka事务提供了确保消息处理一次且仅一次的语义。
（2）跨越多个主题或分区的操作
当需要确保多个主题或分区上的消息同时提交或回滚时，Kafka事务非常有用。
（3）原子性的写入和读取操作
在需要同时写入和读取多个消息并确保一致性的应用中，Kafka事务可以保证数据的完整性。
十、Kafka监控
1.常用的监控指标
（1）Broker 相关指标
Broker CPU 使用率：监控 Kafka Broker 的 CPU 使用情况。
内存使用率：跟踪 Kafka Broker 的内存使用情况，包括堆内存和非堆内存。
磁盘使用率：监控 Kafka Broker 存储磁盘的使用情况，确保不会出现磁盘空间不足的问题。
网络流量：监控 Broker 的入站和出站网络流量，确保网络带宽足够支持流量需求。
（2）Topic 相关指标
消息速率：每个 Topic 的消息生产和消费速率，帮助识别热点 Topic。
分区健康：每个分区的 ISR（In-Sync Replicas）数量和领导者是否正常。
副本延迟：副本之间的同步延迟，确保消息复制正常。
（3）消费者组相关指标
消费者组 lag：消费者组落后于最新消息的量，帮助识别消费者是否能够跟上生产者的速率。
消费者健康：消费者组中每个消费者的运行状态和消费速率。
重新平衡延迟：消费者组重新平衡所花费的时间。
（4）ZooKeeper 相关指标
ZooKeeper 连接状态：监控 Kafka Broker 与 ZooKeeper 的连接状态。
ZooKeeper 健康状态：ZooKeeper 的 CPU 使用率、内存使用率和请求响应时间。
2.常用的 Kafka 监控工具
（1）Kafka Manager
开源的 Kafka 管理和监控工具，提供了集群状态、Topic 和分区的管理，以及消费者组和监控指标的展示。
（2）Kafka Monitor
LinkedIn 开源的 Kafka 监控工具，提供了对 Kafka 健康状况、消息复制情况、消息延迟等细粒度监控。
（3）Confluent Control Center
Confluent 提供的商业监控工具，提供了广泛的 Kafka 监控、告警和管理功能，适用于企业级应用。
（4）Prometheus + Grafana
使用 Prometheus 进行度量收集，Grafana 进行数据可视化，可以灵活监控 Kafka 的各种指标。
十一、Kafka高可用性和扩展性
1.高可用性
顺序写磁盘：充分利用磁盘顺序读写性能（甚至优于内存随机读写）。
零拷贝（Zero-Copy）：通过 sendfile 系统调用，减少内核态与用户态数据拷贝。
批量处理：生产者批量发送消息（linger.ms和batch.size），消费者批量拉取（max.poll.records）。
2.扩展性
Kafka支持水平扩展，可以通过增加Broker节点来提升集群的处理能力。
十二、Kafka生态系统
1.Kafka Connect
用于将 Kafka 与外部系统（如数据库、消息队列等）进行集成的框架，实现数据导入/导出。
2.Kafka Streams
用于处理和分析流数据的 Java 库，可以与 Kafka 集成进行实时流处理，支持实时计算、窗口操作和状态管理。
3.Apache Flink和Apache Spark
这些流处理框架与 Kafka 集成，提供更复杂的实时数据处理功能。
十三、Kafka应用场景
1.实时数据流处理
Kafka广泛用于构建实时流处理平台，如日志收集、监控数据分析等。
2.事件驱动架构
Kafka可以作为事件驱动架构的核心，处理和传递事件。
3.日志收集和分析
Kafka是许多大数据平台中的核心组件，通常用于收集和处理日志数据。
4.数据集成与管道
Kafka常被用作不同系统间的数据传输通道，帮助实现数据的集成和同步。
十四、Kafka与其他消息队列的对比
Kafka与传统的消息队列系统（如RabbitMQ、ActiveMQ）相比，具有更高的吞吐量和更强的持久化能力。
Kafka通过分区和副本机制来保证高可用性，并且非常适合处理大规模的实时数据流。
Kafka的消息可以长期保存（根据配置），而不仅仅是实时传递，因此可以支持大数据分析、日志收集和流处理等应用场景。
十五、总结
Kafka 是一个分布式流处理平台，广泛用于处理大量的实时数据流。它起初由 LinkedIn 开发，并在 2011 年成为 Apache 项目的顶级项目。Kafka 主要用于构建实时数据流处理系统，支持高吞吐量、高可扩展性以及低延迟。
