我们接受了之前的教训，现在把生产者的 acks 设为 all
X
acks=all首领在返回确认或错误响应之前，会等待所有同步副本都收到消息
丢
Leader
fail首领不可用
consumer
重试风险
消费
为 broker 配置了 3 个副本，并且禁用了不完全首领选举，这样应该可以保证万无一失。生产者发送一个消息给首领，首领成功写入，但跟随者副本还没有接收到这个消息。首领向生产者发送了一个响应，告诉它“消息写入成功”，然后它崩溃了，而此时消息还没有被其他副本复制过去。另外两个副本此时仍然被认为是同步的（毕竟判定一个副本不同步需要一小段时间），而且其中的一个副本成了新的首领。因为消息还没有被写入这个副本，所以就丢失了，但发送消息的客户端却认为消息已成功写入。因为消费者看不到丢失的消息，所以此时的系统仍然是一致的（因为副本没有收到这个消息，所以消息不算已提交），但从生产者角度来看，它丢失了一个消息。
follower
写入
acks=1首领在收到消息并把它写入到分区数据文件（不一定同步到磁盘上）时会返回确认或错误响应
acks=all
设置重试次数可以无限重试retries=MAX_INT
选举...
要注意，重试发送一个已经失败的消息会带来一些风险，如果两个消息都写入成功，会导致消息重复。例如，生产者因为网络问题没有收到 broker 的确认，但实际上消息已经写入成功，生产者会认为网络出现了临时故障，就重试发送该消息（因为它不知道消息已经写入成功）。在这种情况下，broker 会收到两个相同的消息。现实中的很多应用程序在消息里加入唯一标识符，用于检测重复消息，消费者在读取消息时可以对它们进行清理。还要一些应用程序可以做到消息的“幂等”，也就是说，即使出现了重复消息，也不会对处理结果的正确性造成负面影响。例如，消息“这个账号里有 110 美元”就是幂等的，因为即使多次发送这样的消息，产生的结果都是一样的。不过消息“往这个账号里增加 10 美元”就不是幂等的。
首领故障，正在选举..
produceracks=all
发送确认
produceracks=1
从上面两个例子可以看出，每个使用 Kafka的开发人员都要注意两件事情：1、根据可靠性需求配置恰当的 acks 值。2、在参数配置和代码里正确处理错误。
acks=1
不可重试错误
在此种模式下的运行速度是非常快的（这就是为什么很多基准测试都是基于这个模式），你可以得到惊人的吞吐量和带宽利用率，不过如果选择了这种模式，一定会丢失一些消息。
success
无效配置
最保险的做法同时也是最慢的做法
acks=0生产者只要能够通过网络把消息发送出去，那么就认为消息已成功写入
为 broker 配置了 3 个副本，并且禁用了不完全首领选举。我们接受了之前的教训，把生产者的 acks 设为 all。假设现在往 Kafka 发送消息，分区的首领刚好崩溃，新的首领正在选举当中，Kafka 会向生产者返回“首领不可用”的响应。在这个时候，如果生产者没能正确处理这个错误，也没有重试发送消息直到发送成功，那么消息也有可能丢失。这算不上是 broker 的可靠性问题，因为 broker 并没有收到这个消息。这也不是一致性问题，因为消费者并没有读到这个消息。问题在于如果生产者没能正确处理这些错误，弄丢消息的是它们自己。
acks=0
可重试错误
可能丢数据，即图1
重试
把生产者发送消息的 acks 设为 1（只要首领接收到消息就可以认为消息写入成功）
