项目实战总结-Kafka实战应用核心要点

一、前言

记录Kafka在项目中应用的核心要点，面试可食用。

二、Kafka避免重复消费

在 Apache Kafka 应用于项目中时，避免重复消费是个重要且常见的问题，尤其是在处理消息时需要确保每条消息只被处理一次。总结而言，避免重复消费的方式有七种：

2.1 消费者组机制

Kafka消费者组（Consumer Group）机制可以确保每个分区的消息只被一个消费者实例消费。通过合理的分区和消费者组设计，可以避免同一消息被多个消费者重复消费。
优点：

• 简单易用，Kafka内置支持。
• 适用于简单的负载均衡和扩展。

缺点：

• 不能完全避免重复消费，比如在消费者重启或重新平衡的过程中可能会有些消息被重复消费。
• 需要额外处理消费者重平衡带来的复杂性。

2.2 幂等生产者

Kafka 0.11.0版本引入幂等生产者（Idempotent Producer），可确保相同的消息在网络或其他错误导致重试时不会被重复写入Kafka。
启用幂等生产者只需要在生产者配置中设置enable.idempotence=true。幂等生产者确保消息在网络或其他错误导致重试时不会被重复写入 Kafka，通过为每个消息分配唯一的序列号来实现幂等性。
配置修改：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("enable.idempotence", "true");
KafkaProducer<String, String> producer = new KafkaProducer<>(props);

优点：

• 简化生产者端的去重逻辑。
• 可以确保消息在Kafka中只写入一次。

缺点：

• 需要Kafka 0.11.0及以上版本。
• 在某些情况下可能会增加生产者的延迟。

2.3 事务性生产者/消费者

Kafka支持事务性消息，允许生产者和消费者在一个事务中一起工作。生产者可以将一组消息作为一个事务写入Kafka，消费者也可以在一个事务中读取和处理消息。这样可确保消息处理的原子性和一致性。要使用事务性生产者，需要配置transactional.id。
配置修改：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("transactional.id", "my-transactional-id");
KafkaProducer<String, String> producer = new KafkaProducer<>(props);
producer.initTransactions();

优点：

• 提供强一致性保证。
• 避免消息处理中的部分提交问题。

缺点：

• 复杂度较高，需Kafka 0.11.0及以上版本。
• 性能开销较大，适用于对一致性要求高的场景。

2.4 手动提交偏移量

Kafka消费者默认会自动提交偏移量（auto commit），为更好地控制消息处理和偏移量提交，可关闭自动提交（enable.auto.commit=false），并在确保消息处理成功后手动提交偏移量。这可通过commitSync()或commitAsync()方法来实现。
配置修改：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("enable.auto.commit", "false");
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        // 处理消息
    }
    consumer.commitSync();
}

优点：

• 精细控制偏移量提交时机，确保消息处理成功后才提交。
• 提高处理的可靠性。

缺点：

• 增加消费者代码的复杂性。
• 如果处理逻辑很慢，可能导致偏移量提交延迟。

2.5 外部存储管理偏移量

在某些特定场景下，可将偏移量存储在外部存储（如数据库）中，而不是依赖 Kafka的内部偏移量管理。这样可在消息处理和偏移量提交之间建立更强的关联，确保只有当消息处理成功后才更新偏移量。
优点：

• 可以在消息处理和偏移量提交之间建立更强的关联。
• 灵活性高，可根据业务需求自定义偏移量管理。

缺点：

• 需要额外的存储和管理逻辑。
• 增加系统的复杂性。

2.6 去重逻辑

在消息处理逻辑中引入去重机制。
例如，可以使用消息的唯一标识符（如消息ID）在处理前检查是否已经处理过该消息，从而避免重复处理。
优点：

• 灵活性高，可根据业务逻辑自定义去重策略。
• 适用于需要严格去重的场景。

缺点：

• 需要额外的存储和管理去重信息。
• 增加处理逻辑的复杂性。

2.7 幂等消息处理逻辑

设计消息处理逻辑时，尽量使其成为幂等操作，即相同的消息即使被处理多次也不会产生副作用。
例如，在数据库操作时，可以使用UPSERT操作（更新插入）来确保数据的一致性。
优点：

• 简化重复消费问题的处理。适
• 用于可以设计为幂等操作的业务场景。

缺点：

• 并不是所有业务逻辑都能设计为幂等操作。
• 需要仔细设计和验证处理逻辑的幂等性。

2.8 小结

对于大多数场景，结合使用消费者组、手动提交偏移量和幂等处理逻辑可以有效避免重复消费，而在需要更严格一致性的场景下，可以考虑使用幂等生产者和事务性消息。
具体选择方案取决于具体的应用场景和需求。

三、Kafka持久化策略

Kafka实际上就是日志消息存储系统， 根据offset获取对应的消息，消费者获取到消息之后该消息不会立即从mq中移除，而是继续存储在磁盘中。

3.1 持久化文件

topic有分区（partition）的概念，Kafka 会将topic分成多个不同的分区，生产者往同一个topic发送的消息最终是发送到不同的分区里面，每个分区中拆分成多个不同的segment文件存储日志。
每个segment文件包含：

• .index 文件 （消息偏移量索引文件）
• .log 文件（消息物理存放文件）
• .timeindex文件（时间索引文件）

每个segment文件容量最大默认为500MB，如果超过500MB就生成新的 segment文件，且文件命名后几位表示上个segment文件最后offset值，如：segment01 、segment500 、segment1000 。
由此可知：一个topic里的消息是由该topic下所有分区里的消息组成的。在同一个分区内部，消息是有序的，而不同分区之间，消息是不能保证有序的。

存储的消息日志文件在 server.properties 配置文件的 log.dirs 参数指定的目录下，以"$topic-$partition"为名称的目录：

注：由于每个分区都有leader的概念，而不同分区的leader可能位于不同的broker上，除leader外，分区还有副本（replica）的概念，因此每个broker只会存储分区leader或副本位于该broker中的topic的消息。

3.2 segment 分段策略

在 server.properties 配置文件中，分段文件配置默认是500MB ，有利于快速回收磁盘空间，重启kafka加载也会加快(如果文件过小，则文件数量比较多，kafka启动时是单线程扫描目录(log.dir)下所有数据文件)，文件较多时性能会稍微降低。下面是相关配置参数：

##日志滚动的周期时间，到达指定周期时间时，强制生成一个新的segment
log.roll.hours=72
##segment的索引文件最大尺寸限制，即时log.segment.bytes没达到，也会生成一个新的segment
log.index.size.max.bytes=10*1024*1024
##控制日志segment文件的大小，超出该大小则追加到一个新的日志segment文件中（-1表示没有限制）
log.segment.bytes=1024*1024*1024

3.3 数据文件刷盘策略

当把数据写入到文件系统之后，数据其实在操作系统的page cache里面，并没有刷到磁盘上去。若此时操作系统宕机，数据就会丢失。
这里可根据消息的数量log.flush.interval.messages和时间log.flush.interval.ms进行配置，如果时间设置的过大，有没达到指定的数量的情况下，如果系统宕机，数据就会丢失。
Kafka官方并不建议通过Broker端的log.flush.interval.messages和log.flush.interval.ms来强制写盘，认为数据的可靠性应该通过Replica来保证，而强制Flush数据到磁盘会对整体性能产生影响。

##每当producer写入10000条消息时，刷数据到磁盘 配置
log.flush.interval.messages=10000
##每间隔5秒钟时间，刷数据到磁盘
log.flush.interval.ms=5000

3.4 日志清理策略

##   是否开启日志清理
log.cleaner.enable=true
##  日志清理运行的线程数
log.cleaner.threads = 2
##  日志清理策略选择有：delete和compact主要针对过期数据的处理，或是日志文件达到限制的额度，会被 topic创建时的指定参数覆盖，默认 delete
log.cleanup.policy = delete
##  数据文件保留多长时间， 存储的最大时间超过这个时间会根据log.cleanup.policy设置数据清除策略
##  log.retention.bytes和 log.retention.minutes或 log.retention.hours任意一个达到要求，都会执行删除
log.retention.minutes=300
log.retention.hours=24
##   topic每个分区的最大文件大小，-1没有大小限制
log.retention.bytes=-1
##  文件大小检查的周期时间，是否触发 log.cleanup.policy中设置的策略
log.retention.check.interval.ms=5minutes

3.5 Kafka消息查找策略

前文提到每个segment file有命名规则，且在.index文件中，存储的是key-value格式的，key代表在.log中按顺序开始顺序消费的offset值，value代表该消息的物理消息存放位置。
但是在.index中不是对每条消息都做记录，它是每隔一些消息记录一次，避免占用太多内存。即使消息不在index记录中，在已有的记录中查找，范围也大大缩小。
kafka就是利用分段+索引的方式来解决查找效率的问题，kafka没有对每个文件建立索引，而是利用kafka 消息写入磁盘的顺序性，对其中部分的消息建立偏移量索引和时间戳索引，这就是稀疏索引，目的是节约空间的资源，定位到相邻.log文件，再根据顺序遍历查找，此方式的时间复杂度是O(n)。
其中，偏移量索引源码：

offsetIndex.append(largestOffset, physicalPosition)
 
def append(offset: Long, position: Int) {
  inLock(lock) {
    // 索引位置
    mmap.putInt(relativeOffset(offset))
    // 日志位置
    mmap.putInt(position)
    _entries += 1
    _lastOffset = offset
  }
}

// 用当前offset减去基准offset
def relativeOffset(offset: Long): Int = {
  val relativeOffset = offset - baseOffset
}

时间戳索引源码：

timeIndex.maybeAppend(maxTimestampSoFar, offsetOfMaxTimestamp)

def maybeAppend(timestamp: Long, offset: Long, skipFullCheck: Boolean = false) {
    inLock(lock) {
      if (timestamp > lastEntry.timestamp) {
        // 添加时间戳
        mmap.putLong(timestamp)
        // 添加相对位移(偏移量索引)
        mmap.putInt(relativeOffset(offset))
        _entries += 1
        _lastEntry = TimestampOffset(timestamp, offset)
      }
    }
}

Kafka使用改进版的二分查找，改的不是二分查找的内部，而是把所有索引项分为热区和冷区 这个改进可以让查询热数据部分时，遍历的Page永远是固定的，这样能避免缺页中断。
整体流程：

四、Kafka零复制(Zero-copy)

Kafka信息复制的原因：确保任何已发布的消息不会丢失，并且可以在机器错误、程序错误或更常见些的软件升级中使用。
Kafka之所以能够快速地处理大量数据，其中一个重要原因就是采用零拷贝（Zero-copy）技术。Kafka采用两种零拷贝技术来提高性能：mmap(memory-map)和sendfile。
主要有两个大的场景：

• Broker 读写.index文件，用 mmap零复制
• Broker 向Consumer发消息，用 sendfile 零复制

mmap (memory-map)：把文件映射到进程的虚拟内存空间。通过对这段内存的读取和修改，可以实现对文件的读取和修改，而不需要用read和write系统调用。
sendfile：直接在内核完成输入和输出，不需要拷贝到用户空间再写出去。

五、Kafka设计实现延迟消息

Kafka延时操作的实现方式：基于时间戳的延时和基于特殊Topic的延时
（1）基于时间戳的延时：通过设置消息的时间戳来实现延时操作。Producer在发送消息时，可以为消息设置一个未来的时间戳，指定消息在该时间点之后才能被消费者消费。Kafka会根据消息的时间戳进行延时推送，直到时间点到达后才将消息发送给消费者。
（2）基于特殊Topic的延时：通过创建专门的延时Topic来实现延时操作。可以将需要延时的消息发送到延时Topic中，然后设置一个定时任务来定期检查延时Topic中的消息，并将到期的消息转发到目标Topic供消费者消费。

简单步骤：

1.创建正常的topic（即即时消费的消息）。
2.创建延迟的topic，并设置合适的副本因子和参数以支持延迟消费。
3.发送消息到正常的topic，同时指定消息需要被延迟消费。
4.使用Kafka的消费者API从延迟topic拉取消息并处理。

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.Producer;
import org.apache.kafka.clients.producer.ProducerRecord;
 
import java.util.Properties;
 
public class DelayedMessageProducer {
 
    public static void main(String[] args) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        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);
 
        // 正常的topic
        String immediateTopic = "immediate-messages";
        // 延迟的topic
        String delayedTopic = "delayed-messages";
 
        // 消息内容
        String value = "This is a delayed message";
 
        // 延迟消费的时间，例如10秒
        long delayTime = 10000;
 
        // 发送消息到延迟的topic
        producer.send(new ProducerRecord<>(delayedTopic, 0, System.currentTimeMillis() + delayTime, value));
 
        producer.close();
    }
}

六、Kafka与ZooKeeper依赖性

从Kafka 2.8版本开始，Kafka提供KRaft模式，需要配置Quorm控制器，可以在没有ZooKeeper的情况下运行Kafka集群。
之前版本，Zookeeper是Kafka的核心组件之一，负责集群元数据的管理和控制器的选举等任务。Zookeeper存储和管理着Kafka的元数据信息和配置信息，包括broker的IP地址、端口号、主题分区的分配方案等。此外，Zookeeper还帮助Kafka集群实现自动故障转移和负载均衡等功能。