Kafka 客户端的缓存管理

前言

Kafka 作为一个高吞吐量的消息队列,它的很多设计都体现了这一点。比如它的客户端,无论是 Producer 还是 Consumer ,都会内置一个缓存用来存储消息。这样类似于我们写文件时,并不会一次只写一个字节,而是先写到一个缓存里,然后等缓存满了,才会将缓存里的数据写入到磁盘。这种缓存机制可以有效的提高吞吐量,本篇文章介绍缓存在 Kafka 客户端的实现原理。

Producer 缓存

我们知道 Producer 发送消息,会先将它存到 RecordAccumulator 的缓存里,等待缓存满了之后,就会发送到服务端。这个缓存的大小,是由内部的内存池控制的。

内存池使用

我们通过观察 RecordAccumulator 的 append 接口,可以看到每次缓存消息之前,都会向内存池申请内存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
public final class RecordAccumulator {
    // 消息缓存队列,以batch格式存储
    private final ConcurrentMap<TopicPartition, Deque<ProducerBatch>> batches;    
    // 内存池
    private final BufferPool free;
    
    public RecordAppendResult append(....) {
        // 计算该消息占用的内存大小    
        int size = Math.max(this.batchSize, AbstractRecords.estimateSizeInBytesUpperBound(maxUsableMagic, compression, key, value, headers));
        // 向内存池申请内存
        buffer = free.allocate(size, maxTimeToBlock);
        .......
    }
}

当消息发送后,会触发 RecordAccumulator 释放内存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
public final class RecordAccumulator {
    // 内存池
    private final BufferPool free;
    
    public void deallocate(ProducerBatch batch) {
        incomplete.remove(batch);
        // 检测是否该消息batch数据太大了,如果太大了则需要切割。所以这种情况不需要释放内存
        if (!batch.isSplitBatch())
            // 向内存池释放内存
            free.deallocate(batch.buffer(), batch.initialCapacity());
    }    
}

内存池结构

使用内存池有两个优点,一个是能够限制内存的使用量,另一个是减少内存的申请和回收频率。虽然 java 支持自动 gc ,但是 gc 也是有成本的。如果之前申请的内存用完之后,还可以重新复用,那么就不会触发 gc。但是内存池的实现有一个难点,那就是如何高效的重新利用。因为每次申请的内存大小都不相同,这样就没办法直接利用了。一种常见的做法是只缓存那些特定大小的内存,对于其他大小的内存则使用后直接丢弃。

我们知道 Kafka 为了提高吞吐量,都是以 batch 格式保存消息。Producer 在实现内存池时,它结合了消息 batch 的特点,试图将每个消息 batch 的大小控制在一定范围内。这样每次申请内存的大小,就可以是相同的。基于这个原因,Kafka 的内存池分为两部分。一部分是特定大小内存块的缓存池,另一个是非缓存池。

当申请的内存大小等于特定的数值,则优先从缓存池中获取。如果缓存池没有,那么需要向非缓存池部分申请内存。等到这块内存使用完后,才会被放入到缓存池等待复用。注意到缓存池的大小是可变的,一开始为零。随着用户申请和释放,才慢慢增长起来的。

如果申请的内存不等于特定的数值,则向非缓存池申请。如果内存空间不够用,那么就需要释放缓存池的内存。

缓存池的内存一般都很少回收,除非是内存空间不足。而非缓存池的内存,都是使用后丢弃,等待 gc 回收。

内存池实现

BufferPool 类负责实现内存池,它有两个重要接口:

  • allocate 接口,负责申请内存
  • deallocate 接口,负责释放内存

allocate 接口代码简化如下,它支持用户并发申请内存,里面包含了一个等待的用户队列,队列采用了先进先出的方式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
public class BufferPool {
    private final long totalMemory;  // 整个内存池的总容量
    private long nonPooledAvailableMemory;  // 非缓存池的空闲大小    
    private final int poolableSize;  // 缓存池中,特定内存的大小
    private final ReentrantLock lock;  // 锁用来防治并发
    private final Deque<ByteBuffer> free;  // 缓存池中的空闲内存块
    private final Deque<Condition> waiters;  // 等待申请的用户

    // 参数size表示申请的内存大小,参数maxTimeToBlockMs表示等待的最长时间
    public ByteBuffer allocate(int size, long maxTimeToBlockMs) throws InterruptedException {
        if (size > this.totalMemory)
            throw new IllegalArgumentException("...")
        ByteBuffer buffer = null;
        this.lock.lock();
        // 如果申请大小等于指定的值,并且缓存池中有空闲的内存块,则直接返回
         if (size == poolableSize && !this.free.isEmpty())
             return this.free.pollFirst();
        // 计算总的空闲内存大小, 等于缓存池的大小 + 非缓存池的空闲大小
        int freeListSize = freeSize() * this.poolableSize;
        if (this.nonPooledAvailableMemory + freeListSize >= size) {
            // 如果空闲内存足够,那么需要保证非缓存池的空闲空间足够
            // 因为所有的内存分配都是从非缓存池开始
            freeUp(size);
            this.nonPooledAvailableMemory -= size;
        } else {
            // 如果空闲内存不够,那么需要等待别的用户释放内存
            int accumulated = 0; // 表示已经成功申请的内存大小
            Condition moreMemory = this.lock.newCondition();
            
            long remainingTimeToBlockNs = TimeUnit.MILLISECONDS.toNanos(maxTimeToBlockMs);
            // 添加到等待集合中
            this.waiters.addLast(moreMemory);
            // 循环等待
            while (accumulated < size) {
                ......
                // 等待通知
                waitingTimeElapsed = !moreMemory.await(remainingTimeToBlockNs, TimeUnit.NANOSECONDS);
                if (waitingTimeElapsed) {
                    // 超过等待时间还没有分配到足够的内存,那么就抛出异常
                    throw new TimeoutException("Failed to allocate memory within the configured max blocking time " + maxTimeToBlockMs + " ms.");
                }
                // 如果申请大小等于指定的值,而这时刚好有其他用户释放了内存,那么就直接从缓存池中获取
                if (accumulated == 0 && size == this.poolableSize && !this.free.isEmpty()) {
                    buffer = this.free.pollFirst();
                    accumulated = size;
                } else {
                    // 继续释放足够的内存
                    freeUp(size - accumulated);
                    // 计算可以分配的内存大小
                    int got = (int) Math.min(size - accumulated, this.nonPooledAvailableMemory);
                    // 更改非缓存池的空闲内存大小
                    this.nonPooledAvailableMemory -= got;
                    accumulated += got;
                }
            }

            // 这里会检查是否还有剩下的空闲内存,如果有则需要通知下一个用户。
            // 因为这时可能有多个用户都释放了内存,而用户释放内存只会通知第一个用户(也就是当前用户),而下个用户还在一直等待中,如果当前用户不主动通知的话,可能造成下个用户等待超时。
            if (!(this.nonPooledAvailableMemory == 0 && this.free.isEmpty()) && !this.waiters.isEmpty())
                    this.waiters.peekFirst().signal();
            
            // 运行到这里,说明已经成功了申请到了内存          
            if (buffer == null)
                // 表示buffer不是从缓存池中获取的,需要执行内存分配
                return safeAllocateByteBuffer(size);
            else:
                // 已经从缓存池中获取到了,则直接返回
                return buffer;
        }
    }
}   

deallocate 接口的源码比较简单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class BufferPool {
    
    public void deallocate(ByteBuffer buffer) {
        deallocate(buffer, buffer.capacity());
    }

    public void deallocate(ByteBuffer buffer, int size) {
        lock.lock();
        try {
            // 如果释放的内存大小等于指定的值,那么就将它添加到缓存池。free列表存储这些内存块
            if (size == this.poolableSize && size == buffer.capacity()) {
                buffer.clear();
                this.free.add(buffer);
            } else {
                // 否则更新非缓存池的空闲大小,这个ByteBuffer实例等待jvm自动gc
                this.nonPooledAvailableMemory += size;
            }
            // 通知队列的第一个用户
            Condition moreMem = this.waiters.peekFirst();
            if (moreMem != null)
                moreMem.signal();
        } finally {
            lock.unlock();
        }
    }
}

Consumer 缓存

Consumer 从服务端获取消息,也是以消息 batch 的格式获取,然后存到缓存里。KafkaConsumer 提供了 poll 方法读取消息。它的原理是从缓存里直接获取,如果缓存里没有,才会向服务端发出请求。

Fetcher 使用了一个队列,来缓存从服务端获取的响应。当用户从缓存中读取消息时,会依次从队列里解析响应,返回消息。但是用户一次不能获取过多数量的消息,这个阈值由配置项 max.poll.records 指定,默认为500。

Fetcher 类还负责与服务端的交互。这里主要关注两个接口

  • fetchedRecords,负责读取缓存消息
  • sendFetches,负责发送请求

KafkaConsumer 读取消息的过程如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
public class KafkaConsumer<K, V> implements Consumer<K, V> {
    
    private final Fetcher<K, V> fetcher; // 消息缓存
    
    // poll 方法做过简化,省略了Metadata和topic subcribe的步骤 
    private ConsumerRecords<K, V> poll(final long timeoutMs, final boolean includeMetadataInTimeout) {
        // 调用 pollForFetches 获取消息
        final Map<TopicPartition, List<ConsumerRecord<K, V>>> records = pollForFetches(remainingTimeAtLeastZero(timeoutMs, elapsedTime));
        if (!records.isEmpty()) {
            // 注意到这里,成功获取之后,还会调用sendFetches方法,发送请求
            // 因为kafka发送请求都是异步的,这里提前发出请求,可以有效的减少下次缓存为空而需要等待请求的时间
            if (fetcher.sendFetches() > 0 || client.hasPendingRequests()) {
                client.pollNoWakeup();
            }
            return this.interceptors.onConsume(new ConsumerRecords<>(records));
        }
    }
    
    private Map<TopicPartition, List<ConsumerRecord<K, V>>> pollForFetches(final long timeoutMs) {
        // 首先从缓存中尝试读取
        final Map<TopicPartition, List<ConsumerRecord<K, V>>> records = fetcher.fetchedRecords();
        if (!records.isEmpty()) {
            return records;
        }

        // 如果缓存为空,则向服务端发出请求
        fetcher.sendFetches();
        // 等待服务端的响应
        client.poll(pollTimeout, startMs, () -> {
            // hasCompletedFetches 表示是否有成功的响应
            return !fetcher.hasCompletedFetches();
        });
        // 从缓存中获取消息
        return fetcher.fetchedRecords();
    }
}

我们注意到 Consumer 在每次读取消息之后,都会触发一次发送请求,这样对于提高性能有好处,减少了下一次的请求等待时间。但是这样会存在一个问题,假想我们把 max.poll.records 设置为 1,这样每次从服务端返回的消息数量都比 1 大,那么缓存就会持续的增长,造成 OOM。

其实 Fetcher 每次发送请求,并不是拉取所有分区的消息。它的 fetchablePartitions 方法决定了请求的分区,它会检查分区在缓存中是否有对应的消息,如果有那么就不请求。这样就基本保证了缓存里拥有每个分区的消息。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class Fetcher<K, V> implements SubscriptionState.Listener, Closeable {
    // CompletedFetch代表着响应,对应着一个分区的消息
    private final ConcurrentLinkedQueue<CompletedFetch> completedFetches;
    
    private List<TopicPartition> fetchablePartitions() {
        // 存储着哪些分区不需要请求
        Set<TopicPartition> exclude = new HashSet<>();  
        // 获取分配的分区
        List<TopicPartition> fetchable = subscriptions.fetchablePartitions();
        // nextInLineRecords 表示正在解析的响应
        if (nextInLineRecords != null && !nextInLineRecords.isFetched) {
            exclude.add(nextInLineRecords.partition);
        }
        // 如果在缓存里,该分区已经有了消息,则不需要请求
        for (CompletedFetch completedFetch : completedFetches) {
            exclude.add(completedFetch.partition);
        }
        // 剔除掉那些不需要请求的分区
        fetchable.removeAll(exclude);
        return fetchable;
    }
}

对于请求,不仅有分区的限制,还有每次请求返回的数据大小限制。不然如果一次请求的数据过大,容易造成内存溢出。我们可以观察请求的格式,发现有多个值来限制请求大小。

  • max_bytes,表示响应数据的最大长度。可以通过配置 fetch.max.bytes 来指定,默认为 50MB
  • min_bytes,表示响应数据的最小长度。可以通过配置 fetch.min.bytes 来指定,默认为 1B

每次请求还包含了多个分区,对于每个分区返回的数据大小,也有限制。通过配置 max.partition.fetch.bytes 来指定,默认为 1MB。这样我们能够粗略的计算出缓存的大小,分配的分区数量 * max.partition.fetch.bytes 。

updatedupdated2023-07-022023-07-02