Kafka 生产者与可靠性保证ACK（2）

生产者消息发送流程

消息发送的总体流程，生产端主要由两个线程协调运行。分别是main线程和sender线程（发送线程）。java

在Kafka（2.6.0版本）源码中，能够看到。spring

源码地址： 
kafka\clients\src\main\java\org.apache.kafka.clients.producer.KafkaProducer.java

测试入口：
KafkaProducerTest.testInvalidGenerationIdAndMemberIdCombinedInSendOffsets()

在建立KafkaProducer时，在430建立了一个Sender对象，而且启动了一个IO线程。apache

this.errors = this.metrics.sensor("errors");
this.sender = newSender(logContext, kafkaClient, this.metadata);
String ioThreadName = NETWORK_THREAD_PREFIX + " | " + clientId;
this.ioThread = new KafkaThread(ioThreadName, this.sender, true);
this.ioThread.start();

interceptor

interceptor的做用是实现消息的定制化，相似：spring Interceptor 、MyBatis的插件、Quartz的监听器。服务器

@Override
public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback) {
     // intercept the record, which can be potentially modified; this method does not throw exceptions
     ProducerRecord<K, V> interceptedRecord = this.interceptors.onSend(record);
    return doSend(interceptedRecord, callback);
}

可经过实现org.apache.kafka.clients.producer.ProducerInterceptor接口开发自定义器。网络

简单自定义例子：app

public class CustomInterceptor implements ProducerInterceptor<String, String> {
    // 发送消息时触发
    @Override
    public ProducerRecord<String, String> onSend(ProducerRecord<String, String> record) {
        System.out.println("发送消息时触发");
        return record;
    }

    // 收到服务端的ACK时触发
    @Override
    public void onAcknowledgement(RecordMetadata metadata, Exception exception) {
        System.out.println("消息被服务端接收");
    }

    @Override
    public void close() {
        System.out.println("生产者关闭");
    }

    // 用键值对配置时触发
    @Override
    public void configure(Map<String, ?> configs) {
        System.out.println("configure...");
    }
}

// 生产者中添加
List<String> interceptors = new ArrayList<>();
interceptors.add("com.freecloud.plug.kafka.interceptor.CustomInterceptor");
props.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG, interceptors);

序列化

byte[] serializedKey;
try {
    serializedKey = keySerializer.serialize(record.topic(), record.headers(), record.key());
} catch (ClassCastException cce) {
    throw new SerializationException("Can't convert key of class " + record.key().getClass().getName() +
            " to class " + producerConfig.getClass(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG).getName() +
            " specified in key.serializer", cce);
}
byte[] serializedValue;
try {
    serializedValue = valueSerializer.serialize(record.topic(), record.headers(), record.value());
} catch (ClassCastException cce) {
    throw new SerializationException("Can't convert value of class " + record.value().getClass().getName() +
            " to class " + producerConfig.getClass(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG).getName() +
            " specified in value.serializer", cce);
}

在kafka针对不一样的数据类型作了相应的序列化工具。如需自定义实现org.apache.kafka.common.serialization.Serializer接口。分布式

路由器（分区器）

int partition = partition(record, serializedKey, serializedValue, cluster);

消息累加器

RecordAccumulator.RecordAppendResult result = accumulator.append(tp, timestamp, serializedKey,
                    serializedValue, headers, interceptCallback, remainingWaitMs, true, nowMs);

// RecordAccumulator本质是一个ConcurrentMap：ide

private final ConcurrentMap<TopicPartition, Deque<ProducerBatch>> batches;

一个partition一个Batch。batch满了以后，会唤醒Sender线程发送消息。工具

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);
    this.sender.wakeup();
}

数据可靠性保证ACK

生产者发送一条消息到服务器如何确保服务器收到消息？若是在发送过程当中网络出了问题，或者kafka服务器接收的时候出了问题，这个消息发送失败了，生产者是不知道的。性能

因此kafka服务端须要使用一种响应客户端的方式，只有在服务端确认之后，生产者才发一下条消息，不然从新发送数据。

那何时才算接收成功？由于消息存储在不一样的broker里，因此是在写入到磁盘以后响应生产者。

服务端响应策略

在分布式场景中，只有一个broker写入成功仍是不够的，若是有多个副本，follower也要写入成功才行。

服务端发送ACK给生产者通常有如下几种策略。

只要leader成功接收就能够，会产生副本与leader不一致状况，若是leader出问题可能会出现数据丢失风险。客户端等待时间最短。
须要半数以上的follower节点完成同步，这种方式客户端等待的时间比上边稍长一点，但能够确保大部分场景不出问题。
须要全部follwer所有完成同步，客户端等待时间最长，但若是节点挂掉的影响相对来讲最小，由于全部节点的数据都是完整的。

kafka的ACK应答机制就使用了以上三种方式。能够经过配置acks参数进行配置。

ISR （in-sync replica set）

上边第三种方式若是保证全部follower同步数据成功？

假设leader接收到数据，全部follower都开始同步数据，可是有一个follower出了问题，没办法从leader同步数据，按这个规则，leader就要一直等待，没法返回ack，成了害群之马。

因此咱们该若是解决这个问题呢？接下来咱们把规则修改一下，不是全部follower都有权利让leader等待，而是只有那些正常工做的follower同步数据的时候才会等待。

把那些正常和leader保持同步的副本维护起来，放到一个动态set里，这个就叫作in-sync replica set (ISR)。只要ISR里面的follower同步完数据以后，就能够给客户端发送ACK。

对于常常出问题的follower能够设定replica.lag.time.max.ms=30（默认30秒），若是超过配置时间才会从isr中剔除。

参数	说明
acks = 0	Producer不等待broker的ack，brokder一接收到还没写入磁盘就返回，当brokder故障时有可能丢失数据；
acks = 1	Producer等待brokder的ack，partition的leader成功落盘后返回ack，若是在follower同步成功前leader故障，将会丢失数据；
acks = -1	producer等待brokder的ack，partition的leader和follower所有成功落盘后才返回ack；

以上三种机制性能依次递减（producer吞吐量下降），数据健壮性则依次递增。实际开发中可根据不一样场景选择不一样的策略。