kafka producer源码分析2 -- RecordAccumulator

这篇文章重点讲一下kafka producer端一个重要的组件——RecordAccmulator。首先，我们以一个结构简图以及一个流程图来简单描述一下RecordAccumulator是如何存放一条KafkaRecord的。

整体流程

RecordAccumulator内部结构简图

追加消息的简单流程图

上面的流程图中只是简单描述了一下追加的过程，让大家对RecordAccumulator先有一个初步的认识，其实实际在追加消息的过程中还有很多很严谨的步骤，在这一小节中我们先不体现。不过从这个简略的流程中，我们可以看到这个流程主要就涉及到RecordAccumulator内部batches以及BufferPool两个重要的成员变量。下面我们就详细地介绍一下这两个核心成员变量；

核心成员变量

两个核心成员变量在RecordAccumulator中的形式：

    private final ConcurrentMap> batches;
    private final BufferPool free;

batches

batches这个组件我们在源码分析1文章中提到过，是一个以TopicPartition为key的map，其中每一个分区有一个自己的队列，队列中的元素称之为ProducerBatch，代表多个ProducerRecord的集合。
上面的那副简图在每一个ProducerBatch中画了一个ByteBuffer内存空间用于存储record的信息，那我们进一步来看看ProducerBatch这个类内部是一个什么样的结构。
这个类内部我们也是重点关注两个成员变量：

    final TopicPartition topicPartition;
    private final MemoryRecordsBuilder recordsBuilder;

topicPartition就是代表这个ProducerBatch属于哪一个分区。那么recordsBuilder这个变量自然就是用于存储“多个ProducerRecord的组件啦。发现其实并没有我们上面提到的ByteBuffer，反而多出来一个recordsBuilder的变量，那我们猜测应该是recordsBuilder内部应该维护了这个ByteBuffer。所以我们再稍微深入一下，简单来看一下这个MemoryRecordsBuilder内部又是一个什么样子。
MemoryrecordsBuilder这个类内部稍微有些复杂，不过可以理解包含两部分内容，一部分内容是下面这些元数据信息：

    private final byte magic;
    private final long logAppendTime;
    private final int partitionLeaderEpoch;
    private boolean isTransactional;
    private long producerId;
    private short producerEpoch;

这些内容大家可以先不关心，之后用到的时候会慢慢说。
还有一部分内容是真正用于存放每一个ProducerRecord的key以及value的位置

    private DataOutputStream appendStream;
    private final ByteBufferOutputStream bufferStream;

到这里我们还是没有找到ByteBuffer的身影，不要着急，我们可以稍微注意一下里面的bufferStream这个成员变量，它的类型是一个ByteBufferOutputStream，这是kafka自定义的一个OutputStream，其实其内部就是简单维护了一个ByteBuffer用于真实的存放序列化好的数据。

public class ByteBufferOutputStream extends OutputStream {

    private static final float REALLOCATION_FACTOR = 1.1f;

    private final int initialCapacity;
    private final int initialPosition;
    private ByteBuffer buffer;

好的，到现在为止，我们一层一层的向内深入，终于到了实际存储数据的这个ByteBuffer所在的位置。但是这个过程经过了很多类，比如MemoryRecordsBuilder，比如ByteBufferOutputStream，这些类我们之后在真正一行一行分析源代码的时候会慢慢说，这里大家只要弄懂了ByteBuffer存放的位置就可以啦。

BufferPool

下面让我们将目光移回到RecordAccmulator上，因为还有一个核心成员变量还没有说，它就是

    private final BufferPool free;

其实上面也简单提了一下，我们每次新建一个ProducerBatch的时候都需要向BufferPool申请一块ByteBuffer，然后将这个ByteBuffer一层一层的注入到ProducerBatch的内部，那我们接下来就来看看这个BufferPool内部是什么样子的，它又是如何分配ByteBuffer的。
关于BufferPool，如果想要展开讲的话，又需要很大的篇幅，我这里专门为这个组件开了一篇文章，大家可以参考我的kafka producer源码分析3这篇文章。

这里提一下，为什么RecordAccumulator内部存储ProducerBatch是以我们常见的容器存储的，像什么map、queue等，但是到了ProducerBatch内部就把所有的ProducerRecord都塞进了一个ByteBuffer中呢？
我们可以这样想，kafka在producer端不管中间过程经历了哪些步骤，最终的目的都是将消息发送给broker。那么是不是可以来一条消息就发一条消息呢？当时是可以的，但是这样效率比较低，其中一个原因就是需要频繁的IO操作，网络开销是很大的，而且这样同步发送，发送的IO操作势必会拖慢业务线程；于是想到了可以攒一批消息一起发送，这个一批的概念就是ProducerBatch，那么在哪里攒呢？于是有了RecordAccumulator。由此可见，ProducerBatch 相当于是网络发送的最小消息单元。所以为了使消息在内存中的存储更加紧凑，使用ByteBuffer来存储ProducerBatch内的数据无疑是最好的选择了。
那为什么RecordAccumulator中没有直接搞一个大的ByteBuffer存储所有待发送的数据呢？因为我们还是需要一些数据的分类的，比如不同的TopicPartition的分类，这样搞一个容器存储就更加方便了。