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 。

 

rel:https://zhmin.github.io/2019/07/24/kafka-client-buffer-manage/