Kafka RecordAccumulator源码

RecordAccumulator

其作用相当于一个缓冲队列,会根据主题和分区(TopicPartition对象)对消息进行分组,每一个TopicPartition对象会对应 一个双端队列Deque<ProducerBatch>,ProducerBatch表示一批消息,在KafkaProducer发送消息时,总是从队列队尾 (Tail)取出ProducerBatch(如果队列不为空),而Sender是从队列头(Head)取ProducerBatch进行处

RecordAccumulator里面包含 ConcurrentMap<TopicPartition, Deque<RecordBatch>> batches；

ConcurrentMap-->实现类 CopyOnWriteMap

TopicPartition-->对应的分区

Deque<RecordBatch>  RecordBatch包含多个MemoryRecords，才是真正放消息的地方

大致结构

ConcurrentMap<TopicPartition, Deque<RecordBatch>> batches; 

所以Kafka这个核心数据结构在这里之所以采用CopyOnWriteMap思想来实现，就是因为这个Map的key-value对，其实没那么频繁更新。也就是TopicPartition-Deque这个key-value对，更新频率很低。

但是他的get操作却是高频的读取请求，因为会高频的读取出来一个TopicPartition对应的Deque数据结构，来对这个队列进行入队出队等操作，所以对于这个map而言，高频的是其get操作。

这个时候，Kafka就采用了CopyOnWrite思想来实现这个Map，避免更新key-value的时候阻塞住高频的读操作，实现无锁的效果，优化线程并发的性能。

 

 

MemeoryRecords里面有下面四个字段比较重要：
buffer：用于保存消息数据的java NIO ByteBuffer
writeLimit：记录buffer字段最多可以写入多少个字节的数据
compressor：压缩器，对消息数据进行压缩，然后将压缩的数据输出到buffer。
writable：标记是只读模式还是可写模式
 

public Compressor(ByteBuffer buffer, CompressionType type) {
		//保存压缩的类型，和buffer开始的位置
        this.type = type;
        this.initPos = buffer.position();

        this.numRecords = 0;
        this.writtenUncompressed = 0;
        this.compressionRate = 1;
        this.maxTimestamp = Record.NO_TIMESTAMP;

        if (type != CompressionType.NONE) {
            // for compressed records, leave space for the header and the shallow message metadata
            // and move the starting position to the value payload offset
            buffer.position(initPos + Records.LOG_OVERHEAD + Record.RECORD_OVERHEAD);
        }

        // 创建合适的输入流
        bufferStream = new ByteBufferOutputStream(buffer);
        //根据压缩类型创建压缩流
        appendStream = wrapForOutput(bufferStream, type, COMPRESSION_DEFAULT_BUFFER_SIZE);
    }

 

再Compressor的构造方法里面最终会调用wrapForOutput方法为当前的buffer创建指定类型的压缩流

public static DataOutputStream wrapForOutput(ByteBufferOutputStream buffer, CompressionType type, int bufferSize) {
        try {
            switch (type) {
                case NONE:
                    return new DataOutputStream(buffer);
                case GZIP:
                    return new DataOutputStream(new GZIPOutputStream(buffer, bufferSize));
                case SNAPPY:
                    try {
                        OutputStream stream = (OutputStream) snappyOutputStreamSupplier.get().newInstance(buffer, bufferSize);
                        return new DataOutputStream(stream);
                    } catch (Exception e) {
                        throw new KafkaException(e);
                    }
                case LZ4:
                    try {
                        OutputStream stream = (OutputStream) lz4OutputStreamSupplier.get().newInstance(buffer);
                        return new DataOutputStream(stream);
                    } catch (Exception e) {
                        throw new KafkaException(e);
                    }
                default:
                    throw new IllegalArgumentException("Unknown compression type: " + type);
            }
        } catch (IOException e) {
            throw new KafkaException(e);
        }
    }

在wrapForOutput方法里面主要也是根据指定的压缩类型创建输出流，所以说，在Compressor中通过利用装饰者模式使buffer有了自动扩容和压缩的功能。
下面我们机选看MemoryRecords里面几个比较重要的方法：
emptyRecords：我们只能通过它来返回MemoryRecords对象
append：首先会判断是否是可写模式，然后调用Compressor的put方法
hasRoomFor：根据Compressor估算已写字节数
close：当有扩容的情况时，MemoryRecords.buffer字段ByteBufferOutputStream.buffer字段所指向的不再是同一个ByteBuffer对象，所以close方法会将MemoryRecords.buffer指向扩容后的对象，同时，设置为只读模式。
sizeInBytes：对于可写返回的是ByteBufferOutputStream.buffer大小，对于只读返回的是MemoryRecords.buffer大小
下面来看一下RecordBatch的核心方法：

public FutureRecordMetadata tryAppend(long timestamp, byte[] key, byte[] value, Callback callback, long now) {
		//判断是否还有空间
        if (!this.records.hasRoomFor(key, value)) {
            return null;
        } else {