Kafka的ack機制，指的是producer的消息發送確認機制，這直接影響到Kafka集群的吞吐量和消息可靠性。而吞吐量和可靠性就像硬幣的兩面，兩者不可兼得，只能平衡。
ACK有3個可選值，分別是1，0，-1。
ACK = 0 時， 發送一次 不論leader是否接收
ACK = 1 時， 等待leader接收成功即可
ACK = -1 時 ，需等待leader將消息同步給follower
（1）ack=1，簡單來說就是，producer只要收到一個分區副本成功寫入的通知就認為推送消息成功了。這里有一個地方需要注意，這個副本必須是leader副本。只有leader副本成功寫入了，producer才會認為消息發送成功。
ack=1的情況下，producer只要收到分區leader成功寫入的通知就會認為消息發送成功了。如果leader成功寫入后，還沒來得及把數據同步到follower節點就掛了，這時候消息就丟失了。
注意，ack的默認值就是1。這個默認值其實就是吞吐量與可靠性的一個折中方案。生產上我們可以根據實際情況進行調整，比如如果你要追求高吞吐量，那么就要放棄可靠性。
（2）ack=0，簡單來說就是，producer發送一次就不再發送了，不管是否發送成功。
提供了最低的延遲。但是最弱的持久性，當服務器發生故障時，就很可能發生數據丟失。
例如leader已經死亡，producer不知情，還會繼續發送消息broker接收不到數據就會數據丟失
（3）ack=-1，簡單來說就是，producer只有收到分區內所有副本的成功寫入的通知才認為推送消息成功了。