标签：2000Wtps 分区 Broker Kafka topic 队列 消息 节点

文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录 博客园版 为您奉上珍贵的学习资源 ：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你 实现技术自由，完成职业升级， 薪酬猛涨！加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领

免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取

---

网易一面：单节点2000Wtps，Kafka高性能原理是什么？

说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如网易、有赞、希音、百度、网易、滴滴的面试资格，遇到一几个很重要的面试题：

问题1：单节点2000Wtps，Kafka高性能原理是什么？

问题2：做过Kafka 进行性能压测吗？单个节点的极限处理能力是多少？是怎么做到的？

注意，单个节点的极限处理能力接近每秒 2000万 条消息，吞吐量达到每秒 600MB

那 Kafka 为什么这么快？如何做到这个高的性能？

尼恩提示，Kafka相关的问题，是开发的核心知识，又是线上的重点难题。

所以，这里尼恩给大家做一下系统化、体系化的线程池梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典》V100版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请从公众号 【技术自由圈】获取。

这里，主要从这 3 个角度来分析：

• 生产端
• 服务端 Broker
• 消费端

先来看下生产端发送消息，Kafka 做了哪些优化？

本文目录

目录

• 网易一面：单节点2000Wtps，Kafka高性能原理是什么？
  • 说在前面
  • 本文目录
  • 一、生产端 Producer
    • 生产者发送消息流程
    • 前置知识：队列缓存+批量写入架构
    • 生产者发送消息流程源码
      • 1. 将消息封装成ProducerRecord对象：
      • 2. Serializer对消息的key和value做序列化：
      • 3. 经过序列化后，会根据自定义的分区器或者Kafka默认的分区器进行获取消息的所属的分区。
      • 4. 获取到消息所属的分区后，消息会被存放到消息缓冲区中（RecordAccumulator）中，
      • 5. 生产者会有一个send线程，用于不断的获取消息和发送消息。
      • 6. 每个请求都会缓存在一个inFlightRequest缓冲区内，里面为每一个Broker分配了一个队列。
      • 7. selector获取到Request会发往相对应的Broker节点。Broker节点收到Request后会进行ACK确认这个Request
      • 8. 当收到Broker对某个Request的ACK后，会删除inFlightRequest队列中这个Request。然后调用clear方法清除对应的ProducerBatch。
      • 9. 如果发送过程中产生了异常，消息发送会存在重试机制。条件为重试次数小于指定值&&异常为RetriableException
    • 生产端的高并发核心架构设计
  • 二、服务端 Broker
    • 1、PageCache 加速消息读写
    • 2、Kafka 的文件布局 以及 磁盘文件顺序写入
    • 3、零拷贝 sendfile：加速消费流程
  • 三、消费端 Consumer
  • 说在最后
  • 参考文献
  • 技术自由的实现路径：
    • 实现你的 架构自由：
    • 实现你的 响应式 自由：
    • 实现你的 spring cloud 自由：
    • 实现你的 linux 自由：
    • 实现你的 网络 自由：
    • 实现你的 分布式锁 自由：
    • 实现你的 王者组件 自由：
    • 实现你的 面试题 自由：
  • 免费获取11个技术圣经PDF：

一、生产端 Producer

先来回顾下 Producer 生产者发送消息的流程：

Kafka的源码最核心的是由client模块和core模块构成，用一幅图大致介绍一下生产者发送消息的流程。

生产者发送消息流程

1. 将消息封装成ProducerRecord对象
2. Serializer对消息的key和value做序列化
3. 根据Partitioner将消息分发到不同的分区，需要先获取集群的元数据
4. RecordAccumulator封装很多分区的消息队列，每个队列代表一个分区，每个分区里面有很多的批次，每个批次里面由多条消息组成
5. Sender会从RecordAccumulator拉取消息，封装成批次，发送请求
6. 通过网络将请求发送到kafka集群

前置知识：队列缓存+批量写入架构

队列缓存+批量写入架构，是尼恩反复强调的一个高并发写入架构，

kafka、netty都用到这个架构

kafka的生产者，也用了这个架构。 设计了一个核心组件RecordAccumulator

1. RecordAccumulator：每一个是生产上都会维护一个固定大小的内存空间，主要用于合并单条消息，进行批量发送，提高吞吐量，减少带宽消耗。
2. RecordAccumulator的大小是可配置的，可以配置buffer.memory来修改缓冲区大小，默认值为：33554432（32M）
3. RecordAccumulator内存结构分为两部分

• 第一部分为已经使用的内存，这一部分主要存放了很多的队列。每一个主题的每一个分区都会创建一个队列，来存放当前分区下待发送的消息集合。
• 第二部分为未使用的内存，这一部分分为已经池化后的内存和未池化的整个剩余内存（nonPooledAvailableMemory）。池化的内存的会根据batch.size（默认值为16K）的配置进行池化多个ByteBuffer，放入一个队列中。所有的剩余空间会形成一个未池化的剩余空间。

生产者发送消息流程源码

1. 将消息封装成ProducerRecord对象：

生产者生成某个消息后，ProducerRecord首先会经过一个或多个组成的拦截器链。

2. Serializer对消息的key和value做序列化：

当消息通过所有的拦截器之后，会进行序列化，会根据key和value的序列化配置进行序列化消息内容，生产者和消费者必须使用相同的key-value序列化方式。

// 消息key序列化
properties.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
// 消息value序列化
properties.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

3. 经过序列化后，会根据自定义的分区器或者Kafka默认的分区器进行获取消息的所属的分区。

自定义分区器可以参考下面。

Kafka默认的分区器规则：

• 1）当消息的key存在时，首先获取当前topic下的所有分区数，然后对key进行求hash值，根据hash值和分区总数进行取余，获取所属的的分区。

• 2）如果key不存在时，会根据topic获取一个递增的数值，然后通过和分区数进行取余，获取所属的分区。

Kafka默认分区器源码：

public class DefaultPartitioner implements Partitioner {

    private final ConcurrentMap<String, AtomicInteger> topicCounterMap = new ConcurrentHashMap<>();

    public void configure(Map<String, ?> configs) {}

    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
        int numPartitions = partitions.size();
        if (keyBytes == null) {
            int nextValue = nextValue(topic);
            List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
            if (availablePartitions.size() > 0) {
                int part = Utils.toPositive(nextValue) % availablePartitions.size();
                return availablePartitions.get(part).partition();
            } else {
                // no partitions are available, give a non-available partition
                return Utils.toPositive(nextValue) % numPartitions;
            }
        } else {
            // hash the keyBytes to choose a partition
            return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
        }
    }

    private int nextValue(String topic) {
        AtomicInteger counter = topicCounterMap.get(topic);
        if (null == counter) {
            counter = new AtomicInteger(ThreadLocalRandom.current().nextInt());
            AtomicInteger currentCounter = topicCounterMap.putIfAbsent(topic, counter);
            if (currentCounter != null) {
                counter = currentCounter;
            }
        }
        return counter.getAndIncrement();
    }

    public void close() {}

}

自定义分区器：

public class CustomerPartitions implements Partitioner{
    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        int partition = 0;
        if(key == null) {
        } else {
            String keyStr = key.toString();
            if(keyStr.contains("Test")) {
                partition = 1;
            } else {
                partition = 2;
            }
        }
        return partition;
    }

    @Override
    public void close() {

    }

    @Override
    public void configure(Map<String, ?> configs) {

    }
}

4. 获取到消息所属的分区后，消息会被存放到消息缓冲区中（RecordAccumulator）中，

根据topic和分区可以确定一个双端队列(Deque)中，这个队列中每个节点为多个消息的合集（ProducerBatch）,新的消息会被放到队列的最后一个节点上，存放会存在多种情况。

场景一：消息大小不足16K。

首先会根据topic和分区获取所属队列的最后一个ProducerBatch，

• 如果最后一个ProducerBatch+当前消息 <= 16K时，会把当前消息存入这个ProducerBatch中，等待发送。

• 如果最后一个ProducerBatch+当前消息 > 16K时，此时消息不会放入这个ProducerBatch中，而是会向池化的队列中获取一个ByteBuffer，把这个ByteBuffer放到队列的尾部，然后把消息放入这个新增的ProducerBatch中。

• 如果最后一个ProducerBatch+当前消息 > 16K时，并且池化的队列中没有可用的ByteBuffer时，池化队列会向剩余的未使用的内存空间（nonPooledAvailableMemory）申请一个大小为16K的内存空间，添加到池化队列尾部。然后把这个新增的ByteBuffer添加到分区下的队列尾部，存储新的消息。

场景二：消息大小超过16K

• 当消息超过16K时，任何一个ProducerBatch都无法存储这个消息。此时会直接向剩余的空间（nonPooledAvailableMemory）的进行分配和当前的消息大小一样的内存空间，加到队列的尾部，然后存储消息，等待发送。
• 当剩余的空间（nonPooledAvailableMemory） < 消息大小时，nonPooledAvailableMemory会向池化队列获取空间，每次获取一个ByteBuffer(16K)，直到nonPooledAvailableMemory的空间大于或等于消息大小时。获取的ByteBuffer会经过jvm的GC垃圾回收。过程比较慢。当nonPooledAvailableMemory空间大于获取等于消息大小时，会把分配消息大小的空间放入分区队列的尾部，把消息存入这个ProducerBatch内。

5. 生产者会有一个send线程，用于不断的获取消息和发送消息。

sender线程会不断的扫描RecordAccumulator中所有的ProducerBatch，如果ProducerBatch达到batch.size（默认16K）大小或者最早的一个消息已经等待超过linger.ms（默认为0）时，这个ProducerBatch会被sender线程收集到。由于不同的topic和分区会被分到不同的Broker节点上，sender线程会把发送到相同Broker姐节点的ProducerBatch合并在一个Request请求中，一个Request请求不会超过max.request.size（默认1048576B = 1M）

6. 每个请求都会缓存在一个inFlightRequest缓冲区内，里面为每一个Broker分配了一个队列。

新的请求会放在队列尾部，每个队列最多能够容纳max.in.flight.requests.per.connection（默认值为5）个Request，队列满了不会产生新的Request。

7. selector获取到Request会发往相对应的Broker节点。Broker节点收到Request后会进行ACK确认这个Request

acks 有三个配置值:[-1 , 0 , 1]
acks = -1 表示不需要收到leader节点的ACK回复就会发送下一个Request。高吞吐，低一致性
acks = 0 表示只需要接收到leader节点的ACK后就可以发送下一个Request。
acks = 1 表示 需要接收到leaer节点和ISR节点的ACK后才会发送下一个Request。一致性较高

8. 当收到Broker对某个Request的ACK后，会删除inFlightRequest队列中这个Request。然后调用clear方法清除对应的ProducerBatch。

RecordAccumulator Clear清理场景：针对2.4.1.1，2.4.1.2，2.4.1.3，ProducerBatch都会标记为删除，然后放入池化队列中，不会进行GC。2.4.1.3中从nonPooledAvailableMemory获取的内存也不会归还給nonPooledAvailableMemory，任然存放在池化队列中。
针对2.4.2.1，2.4.2.2，超过16K的消息内存空间会被GC进行回收，然后作为nonPooledAvailableMemory的一部分

9. 如果发送过程中产生了异常，消息发送会存在重试机制。条件为重试次数小于指定值&&异常为RetriableException

private boolean canRetry(ProducerBatch batch, ProduceResponse.PartitionResponse response) {
    return batch.attempts() < this.retries &&
        ((response.error.exception() instanceof RetriableException) ||
         (transactionManager != null && transactionManager.canRetry(response, batch)));
}

生产端的高并发核心架构设计

在消息发送时候，可发现这两个亮点：批量消息和自定义协议格式。

• 批量发送：减少了与服务端 Broker 处理请求的次数，从而提升总体的处理能力。

调用 send() 方法时，不会立刻把消息发送出去，而是缓存起来，选择恰当时机把缓存里的消息划分成一批数据，按批次发送给服务端 Broker。

• 自定义协议格式：序列化方式和压缩格式都能减少数据体积，从而节省网络资源消耗。

各种压缩算法对比：

• 吞吐量方面：LZ4 > Snappy > zstd 和 GZIP

• 压缩比方面：zstd > LZ4 > GZIP > Snappy

Compressor name	Ratio	Compression	Decompress.
zstd 1.3.4-1	2.877	470 MB/s	1380 MB/s
zlib 1.2.11-1	2.743	110 MB/s	400 MB/s
brotli 1.0.2-0	2.701	410 MB/s	430 MB/s
quicklz 1.5.0-1	2.238	550 MB/s	710 MB/s
lzo1x2.09-1	2.108	650 MB/s	830 MB/s
lz4 1.8.1	2.101	750 MB/s	3700 MB/s
snappy 1.1.4	2.091	530 MB/s	1800 MB/s
lzf 3.6-1	2.077	400 MB/s	860 MB/s

二、服务端 Broker

Broker 的高性能主要从这 3 个方面体现：

• PageCache 缓存
• Kafka 的文件布局 以及 磁盘文件顺序写入
• 零拷贝 sendfile：加速消费流程

下面展开讲讲。

1、PageCache 加速消息读写

使用 PageCache 主要能带来如下好处：

• 写入文件的时候：操作系统会先把数据写入到内存中的 PageCache，然后再一批一批地写到磁盘上，从而减少磁盘 IO 开销。

• 读取文件的时候：也是从 PageCache 中来读取数据。

如果消息刚刚写入到服务端就会被消费，按照 LRU 的“优先清除最近最少使用的页”这种策略，读取的时候，对于这种刚刚写入的 PageCache，命中的几率会非常高。

2、Kafka 的文件布局 以及 磁盘文件顺序写入

文件布局如下图所示：

主要特征是：文件的组织方式是“topic + 分区”，每一个 topic 可以创建多个分区，每一个分区包含单独的文件夹。

Kafka 在分区级别实现文件顺序写：即多个文件同时写入，更能发挥磁盘 IO 的性能。

• 相对比 RocketMQ：RocketMQ 在消息写入时追求极致的顺序写，所有的消息不分主题一律顺序写入 commitlog 文件， topic 和 分区数量的增加不会影响写入顺序。

• 弊端： Kafka 在消息写入时的 IO 性能，会随着 topic 、分区数量的增长先上升，后下降。

所以使用 Kafka 时，要警惕 Topic 和 分区数量。

3、零拷贝 sendfile：加速消费流程

当不使用零拷贝技术读取数据时：

流程如下：

1）消费端 Consumer：向 Kafka Broker 请求拉取消息

2）Kafka Broker 从 OS Cache 读取消息到 应用程序的内存空间：

• 若 OS Cache 中有消息，则直接读取；
• 若 OS Cache 中无消息，则从磁盘里读取。

3）再通过网卡，socket 将数据发送给 消费端Consumer

当使用零拷贝技术读取数据：

Kafka 使用零拷贝技术可以把这个复制次数减少一次，直接从 PageCache 中把数据复制到 Socket 缓冲区中。

• 这样不用将数据复制到用户内存空间。

• DMA 控制器直接完成数据复制，不需要 CPU 参与，速度更快。

三、消费端 Consumer

消费者只从 Leader分区批量拉取消息。

为了提高消费速度，多个消费者并行消费比不可少。Kafka 允许创建消费组(唯一标识 group.id)，在同一个消费组的消费者共同消费数据。

举个例子：

• 有两个 Kafka Broker，即有 2个机子
• 有一个主题：TOPICA，有 3 个分区(0, 1, 2)

如上图，举例 4 中情况：

• group.id = 1，有一个消费者：这个消费者要处理所有数据，即 3 个分区的数据。

• group.id = 2，有两个消费者：consumer 1消费者需处理 2个分区的数据，consumer2 消费者需处理 1个分区的数据。

• group.id = 3，有三个消费者：消费者数量与分区数量相等，刚好每个消费者处理一个分区。

• group.id = 4，有四个消费者：消费者数量 > 分区数量，第四个消费者则会处于空闲状态。

说在最后

kafka相关面试题，是非常常见的面试题。

以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。

学习过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

参考文献

https://juejin.cn/post/7134463012563320868

技术自由的实现路径：

实现你的 架构自由：

《吃透8图1模板，人人可以做架构》

《10Wqps评论中台，如何架构？B站是这么做的！！！》

《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》

《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》

《100亿级订单怎么调度，来一个大厂的极品方案》

《2个大厂 100亿级 超大流量 红包 架构方案》

… 更多架构文章，正在添加中

实现你的 响应式 自由：

《响应式圣经：10W字，实现Spring响应式编程自由》

这是老版本 《Flux、Mono、Reactor 实战（史上最全）》

实现你的 spring cloud 自由：

《Spring cloud Alibaba 学习圣经》 PDF

《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》

实现你的 linux 自由：

《Linux命令大全：2W多字，一次实现Linux自由》

实现你的 网络 自由：

《TCP协议详解 (史上最全)》

《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》

实现你的 分布式锁 自由：

《Redis分布式锁（图解 - 秒懂 - 史上最全）》

《Zookeeper 分布式锁 - 图解 - 秒懂》

实现你的 王者组件 自由：

《队列之王： Disruptor 原理、架构、源码 一文穿透》

《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》

《缓存之王：Caffeine 的使用（史上最全）》

《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》

实现你的 面试题 自由：

4800页《尼恩Java面试宝典 》 40个专题

免费获取11个技术圣经PDF：

标签：2000Wtps,分区,Broker,Kafka,topic,队列,消息,节点
From： https://www.cnblogs.com/crazymakercircle/p/17654849.html