网易一面：单节点2000Wtps，Kafka怎么做的？

说在前面

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

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

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

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

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

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

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

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

最新《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取

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

生产端
服务端 Broker
消费端

先来看下生产端发送消息，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
- 说在最后
- 参考文献
- 推荐阅读

一、生产端 Producer

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

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

生产者发送消息流程

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

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

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

kafka、netty都用到这个架构

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

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