kafka15-生产者的吞吐量和延迟优化1

最新推荐文章于 2024-11-14 22:44:50 发布

m0_63833709

最新推荐文章于 2024-11-14 22:44:50 发布

阅读量1k

点赞数 27

分类专栏： kafka原理文章标签： kafka 分布式

本文链接：https://blog.csdn.net/m0_63833709/article/details/140252315

版权

kafka原理专栏收录该内容

23 篇文章 3 订阅

订阅专栏

生产者拦截器优化：大消息场景

生产者端处理

拦截器实现：创建一个实现了ProducerInterceptor接口的类，重写onSend方法来检查消息大小，并根据大小决定处理逻辑。
过滤和存储：如果消息体的大小超过设定的阈值（例如100MB），则不通过Kafka发送整个消息体，而是将消息体存储到HDFS或共享存储（NAS），并将存储位置的元数据信息序列化后发送到Kafka。
发送元数据：只发送指向大容量数据的引用或路径信息，而不是数据本身，从而减少网络传输和序列化的时间和资源消耗。

消费者端处理

反序列化元数据：消费者在接收到消息后，首先反序列化消息内容以获取大容量数据的存储位置信息。
从共享存储读取：根据反序列化得到的元数据信息，从HDFS或共享存储中读取实际的大容量数据。

示例代码

以下是生产者拦截器的一个简单示例：

public class LargeMessageInterceptor implements ProducerInterceptor<String, String> {
    private static final long MAX_MESSAGE_SIZE = 100 * 1024 * 1024; // 100MB

    @Override
    public ProducerRecord<String, String> onSend(ProducerRecord<String, String> record) {
        // 检查消息大小
        if (record.value().length() > MAX_MESSAGE_SIZE) {
            // 存储大消息到HDFS或共享存储，并获取存储路径
            String storagePath = storeLargeMessage(record.value());
            // 返回一个新的记录，包含存储路径而不是原始消息
            return new ProducerRecord<>(record.topic(), record.partition(), record.timestamp(), 
                                        record.key(), storagePath, record.headers());
        }
        return record;
    }

    private String storeLargeMessage(String message) {
        // 实现将消息存储到HDFS或共享存储的逻辑
        // 返回存储路径
        return "hdfs://path/to/large/message";
    }

    @Override
    public void onAcknowledgement(Status status, Exception exception) {
        // 可以处理消息确认或异常
    }

    @Override
    public void close() {
        // 清理资源
    }
}

在生产者配置中添加拦截器：

Properties props = new Properties();
// ... 其他配置 ...
props.put("interceptor.classes", "com.example.LargeMessageInterceptor");
KafkaProducer<String, String> producer = new KafkaProducer<>(props);

消息分区优化

在Kafka中，分区器（Partitioner）的作用是决定如何将消息分配到Topic的不同分区上。这直接影响到数据的并行处理能力和负载均衡。

默认分区策略

无Key消息：如果ProducerRecord中没有指定分区，并且消息的key为null，生产者将使用默认的分区策略。在Kafka 2.4之前，这是RoundRobin策略，而从2.4开始，默认策略变为Sticky分区。

Sticky分区策略

引入原因：为了解决在没有Key的情况下，消息被分散到多个小批量中的问题，这可能导致批处理效率低下和增加延迟。
工作原理：Sticky分区策略尝试将具有null key的消息尽可能填满一个分区的ProducerBatch。当当前分区的ProducerBatch满了之后，分区器会使用RoundRobin策略选择一个新的分区，并“粘附”到这个新分区上，直到该分区的ProducerBatch也满了。

开启Sticky分区策略

自动开启：从Kafka 2.4开始，默认已经开启了Sticky分区策略。
手动设置：如果需要显式设置，可以在生产者配置中指定分区器类

props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, "org.apache.kafka.clients.producer.internals.StickyAssignor");

自定义分区策略

自定义分区器：如果Sticky分区策略不满足需求，可以自定义分区器。通过实现Partitioner接口并重写partition方法，可以控制消息的分区逻辑。
配置自定义分区器：在生产者配置中指定自定义分区器的类名。

示例：自定义分区器

public class CustomPartitioner implements Partitioner {
    @Override
    public void configure(Map<String, ?> configs) {
        // 初始化配置
    }

    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        // 根据key或自定义逻辑来决定分区
        if (key != null) {
            return Math.abs(key.hashCode()) % cluster.partitionCountForTopic(topic);
        }
        // 对于null key，可以使用RoundRobin或其他逻辑
        return (int) (System.currentTimeMillis() / 1000) % cluster.partitionCountForTopic(topic);
    }

    @Override
    public void close() {
        // 清理资源
    }
}

压缩方式优化

在Kafka中，选择合适的压缩类型（compression.type）对于优化网络传输和存储效率至关重要。

压缩类型概述

none：不进行压缩，这是默认设置。
gzip：一种广泛使用的压缩算法，压缩比较高，但CPU占用也较高。
lz4：压缩和解压速度非常快，压缩比较高。
snappy：由Google开发，压缩速度非常快，压缩比适中。
zstd：提供极高的压缩比和较快的压缩速度。

压缩策略选择

压缩比 vs 速度：选择压缩类型时需要平衡压缩比和压缩速度。例如，gzip提供高压缩比，但速度较慢；而lz4和snappy提供较快的速度和合理的压缩比。
CPU占用：压缩和解压缩过程会占用CPU资源。如果系统对CPU敏感，应选择CPU占用较低的压缩算法。
网络和存储效率：压缩可以减少网络传输的数据量和存储需求，提高效率。

实际经验和测试

推荐选择：根据实际经验和压力测试，snappy或lz4通常提供最佳的速度和压缩比平衡。

Kafka配置注意事项

生产者配置：在生产者配置中设置compression.type，以启用压缩。
compression.type=snappy
Broker配置：确保Broker端的compression.type设置为producer，以避免双重压缩。
compression.type=producer
一致性：生产者端的压缩算法必须与Broker端兼容。如果不一致，Broker将先解压缩再使用自己的压缩策略重新压缩，这将增加不必要的CPU和网络负载。

示例：生产者配置

Properties props = new Properties(); 
props.put("bootstrap.servers", "kafka_server:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); 
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); 
props.put("compression.type", "snappy"); // 或 lz4 
KafkaProducer<String, String> producer = new KafkaProducer<>(props);