Kafka成长记9：Kafka内存缓冲区中的消息最终如何发送出去的？

之前三节我们主要分析了KafkaProducer是如何将消息放入到内存缓冲区的。

上面的逻辑只是Accumulator.append()的一段核心逻辑而已，还记得之前我们分析过的KafkaProducerHelloWorld的整体逻辑么？

之前分析的代码逻辑如下图所示：

从最开始配置解析，消息对象Record的创建，到元数据拉取、key和value的最初序列化、Product分区路由的原理、消息如何放入内存缓冲区的原理。

之前我们已经分析到了图中红线的部分的结尾了—唤醒Sender线程发送消息。

这一节我们就继续分析，消息放入了内存缓冲中之后，触发唤醒Sender线程，之后Sender线程如何将打包好Batch发送出去的。

什么条件会唤醒Sender线程

从上面的流程图可以看到，在producer.send()执行doSend()的时候，accumulator.append()将消息内存缓冲器之后，会唤醒Sender线程。

那我们来看下RecordBatch放入缓冲器后，什么条件会唤醒Sender线程呢？

private Future<RecordMetadata> doSend(ProducerRecord<K, V> record, Callback callback) {
    TopicPartition tp = null;
    try {
      // 1.waitOnMetadata 等待元数据拉取
      // 2.keySerializer.serialize和valueSerializer.serialize，很明显就是将Record序列化成byte字节数组
      // 3.通过partition进行路由分区，按照一定路由策略选择Topic下的某个分区
      //省略代码...
      // 4.accumulator.append将消息放入缓冲器中
        RecordAccumulator.RecordAppendResult result = accumulator.append(tp, timestamp, serializedKey, serializedValue, interceptCallback, remainingWaitMs);
        if (result.batchIsFull || result.newBatchCreated) {
            log.trace("Waking up the sender since topic {} partition {} is either full or getting a new batch", record.topic(), partition);
            //5.唤醒Sender线程的selector.select()的阻塞，开始处理内存缓冲器中的数据。
            this.sender.wakeup();
        }
        return result.future;
    } catch (ApiException e) {
        log.debug("Exception occurred during message send:", e);
        if (callback != null)
            callback.onCompletion(null, e);
        this.errors.record();
        if (this.interceptors != null)
            this.interceptors.onSendError(record, tp, e);
        return new FutureFailure(e);
    } catch (Exception e) {
        throw e;
    }
    //省略其他各种异常捕获
}

从上面代码，可以很清楚的看到，唤醒sender线程的逻辑很简单，就是当前Batch已经写满，或者是新的batch创建了。

result.batchIsFull || result.newBatchCreated

那么这两变量什么时候设置的呢？

在上一节中RecordBatch.tryAppned是创建新的batch，而RecordAccumulator.tryAppend()主要是追加写batch。他们会设置batchIsFull和newBatchCreated的标记。表示是新创建还是写满的batch。

主要代码如下：

new RecordAppendResult(future, deque.size() > 1 || last.records.isFull(), false);

new RecordAppendResult(future, dq.size() > 1 || batch.records.isFull(), true)

public final static class RecordAppendResult {
    public final FutureRecordMetadata future;
    public final boolean batchIsFull;
    public final boolean newBatchCreated;

    public RecordAppendResult(FutureRecordMetadata future, boolean batchIsFull, boolean newBatchCreated) {
        this.future = future;
        this.batchIsFull = batchIsFull;
        this.newBatchCreated = newBatchCreated;
    }
}


public boolean isFull() {
    return !this.writable || this.writeLimit <= this.compressor.estimatedBytesWritten();
}

当满足条件后，最终会触发到sender.wakeup() 唤醒之前while循环阻塞的Selector()，准备发送消息。整个过程如下所示：

唤醒的Sender线程如何发送batch消息的？

既然最终触发了sender.wakeUp()，你应该知道底层触发的就是NioSelector的wakeup。唤醒的是哪一个流程呢？我们先来回顾下，之前《Kafka成长记4 元数据拉取 下》Sender线程的run的主要脉络在如下图所示：

也就是之前分析拉取元数据的时候，核心就是NetworkClient.poll()的内部主要3步 maybeUpdate()-->Selector()-->hanlde()。

最终拉取元数据成功后，会再次阻塞在Selector.select()等待，而此时sender.waykeUp()就会唤醒阻塞继续执行run方法了。

但是NetworkClient.poll()外层还有一堆令人迷惑的代码，不知道大家记不记得?

   void run(long now) {
        Cluster cluster = metadata.fetch();
        // get the list of partitions with data ready to send
        RecordAccumulator.ReadyCheckResult result = this.accumulator.ready(cluster, now);

        // if there are any partitions whose leaders are not known yet, force metadata update
        if (result.unknownLeadersExist)
            this.metadata.requestUpdate();

        // remove any nodes we aren't ready to send to
        Iterator<Node> iter = result.readyNodes.iterator();
        long notReadyTimeout = Long.MAX_VALUE;
        while (iter.hasNext()) {
            Node node = iter.next();
            if (!this.client.ready(node, now)) {