本文共 968 字，大约阅读时间需要 3 分钟。

1. kafka为何这么快
   producer: 微批生产
   broker:分布式 顺序写磁盘，PageCache，零拷贝
   顺序写磁盘I/O 600Mb/s
   随机写磁盘I/O 100KB/s
   consumer: 根据分区数并发消费

2. kafka性能优化：
   producer:

分区的多少和客户端的内存没太有直接的关系

buffer.memory=32M 待发送消息的BufferPool（缓冲池）对象，一个producer只有一个BufferPool（缓冲池）对象

batch.size=16kB 存储在BufferPool（缓冲池）对象的一个微批消息的大小。

linger.ms=0

max.in.flight.requests.per.connection=5

该参数指定了生产者在收到服务器响应之前可以发送多少个消息。它的值越高，就会占用越多的内存，不过也会提升吞吐量。把它设为 1 可以保证消息是按照发送的顺序写入服务器的，即使发生了重试。

broker:

num.network.threads=3

num.io.threads=8

queued.max.requests 500

共享请求队列大小 (在阻塞网络线程之前允许的排队请求的数量)，及num.network.threads和num.io.threads的缓存池的大小

num.replica.fetchers=1 副本同步线程

consumer:

根据分区数启动对应的消费者数

num.replica.fetchers=1B

默认是 1 字节，表示只要 Kafka Broker 端积攒了 1 字节的数据，就可以返回给 Consumer 端，例如可以调整为1 KB或者更大。

fetch.max.wait.ms=500ms

通过 fetch.min.bytes 告诉 Kafka，等到有足够的数据时才把它返回给消费者。而 feth.max.wait.ms 则用于指定 broker 的等待时间

注：consumer的num.replica.fetchers、fetch.max.wait.ms和producer的buffer.memory、linger.ms有异曲同工之妙

3. Kafka是如何优化JVM GC问题的

面试官问：上亿数据量下，Kafka是如何优化JVM GC问题的

转载地址：https://blog.csdn.net/yangshengwei230612/article/details/118017470 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！