Kafka3.x核心速查手册二、客户端使用篇-5、发送应答机制

​ 这是在开发过程中比较重要的一个机制，也是面试过程中最喜欢问的一个机制，被无数教程指导吹得神乎其神。所以这里也简单介绍一下。

​ 其实这里涉及到的，就是在Producer端一个不太起眼的属性ACKS_CONFIG。

 	public static final String ACKS_CONFIG = "acks";
    private static final String ACKS_DOC = "The number of acknowledgments the producer requires the leader to have received before considering a request complete. This controls the "
                                           + " durability of records that are sent. The following settings are allowed: "
                                           + " <ul>"
                                           + " <li><code>acks=0</code> If set to zero then the producer will not wait for any acknowledgment from the"
                                           + " server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be"
                                           + " made that the server has received the record in this case, and the <code>retries</code> configuration will not"
                                           + " take effect (as the client won't generally know of any failures). The offset given back for each record will"
                                           + " always be set to <code>-1</code>."
                                           + " <li><code>acks=1</code> This will mean the leader will write the record to its local log but will respond"
                                           + " without awaiting full acknowledgement from all followers. In this case should the leader fail immediately after"
                                           + " acknowledging the record but before the followers have replicated it then the record will be lost."
                                           + " <li><code>acks=all</code> This means the leader will wait for the full set of in-sync replicas to"
                                           + " acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica"
                                           + " remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting."
                                           + "</ul>"
                                           + "<p>"
                                           + "Note that enabling idempotence requires this config value to be 'all'."
                                           + " If conflicting configurations are set and idempotence is not explicitly enabled, idempotence is disabled.";

​ 官方给出的这段解释，已经比任何外部的资料都要准确详细了。如果你理解了Topic的分区模型，这个属性就非常容易理解了。这个属性更大的作用在于保证消息的安全性，尤其在replica-factor备份因子比较大的Topic中，尤为重要。

• ack=0，生产者就不会知道Broker端有没有将消息写入到Partition，吞吐量是最高的，但是数据安全性是最低的。
• ack=all or -1，生产者需要等Broker端的所有Partiton(Leader Partition以及其对应的Follower Partition都写完了才能得到返回结果，这样数据是最安全的，但是每次发消息需要等待更长的时间，吞吐量是最低的。
• ack设置成1，则是一种相对中和的策略。意味着在吞吐量和可靠性之间进行折中处理。实际上，真实使用时，还可以根据你的集群规模选择合适的值。