寫在前面 :
面試大廠時，一旦簡歷上寫了Kafka，幾乎必然會被問到一個問題：說說acks參數對消息持久化的影響？
這個acks參數在kafka的使用中，是非常核心以及關鍵的一個參數，決定了很多東西。所以無論是爲了面試還是實際項目使用，大家都值得看一下這篇文章對Kafka的acks參數的分析，以及背後的原理。
如何保證宕機的時候數據不丟失？
如果要想理解這個acks參數的含義，首先就得搞明白kafka的高可用架構原理。
比如下面的圖裏就是表明了對於每一個Topic，我們都可以設置他包含幾個Partition，每個Partition負責存儲這個Topic一部分的數據。然後Kafka的Broker集羣中，每臺機器上都存儲了一些Partition，也就存放了Topic的一部分數據，這樣就實現了Topic的數據分佈式存儲在一個Broker集羣上。
但是有一個問題，萬一 一個Kafka Broker宕機了，此時上面存儲的數據不就丟失了嗎？
沒錯，這就是一個比較大的問題了，分佈式系統的數據丟失問題，是他首先必須要解決的，一旦說任何一臺機器宕機，此時就會導致數據的丟失。
多副本冗餘的高可用機制
所以如果大家去分析任何一個分佈式系統的原理，比如說zookeeper、kafka、redis cluster、elasticsearch、hdfs等等，其實他都有自己內部的一套多副本冗餘機制，多副本冗餘幾乎是現在任何一個優秀的分佈式系統都一般要具備的功能。
在kafka集羣中，每個Partition都有多個副本，其中一個副本叫做leader，其他的副本叫做follower，如下圖。
如上圖所示，假設一個Topic拆分爲了3個Partition，分別是Partition0，Partiton1，Partition2，此時每個Partition都有2個副本。
比如Partition0有一個副本是Leader，另外一個副本是Follower，Leader和Follower兩個副本是分佈在不同機器上的。
這樣的多副本冗餘機制，可以保證任何一臺機器掛掉，都不會導致數據徹底丟失，因爲起碼還是有副本在別的機器上的。
多副本之間數據如何同步？
接着我們就來看看多個副本之間數據是如何同步的？其實任何一個Partition，只有Leader是對外提供讀寫服務的,也就是說，如果有一個客戶端往一個Partition寫入數據，此時一般就是寫入這個Partition的Leader副本。然後Leader副本接收到數據之後，Follower副本會不停的給他發送請求嘗試去拉取最新的數據，拉取到自己本地後，寫入磁盤中。如下圖所示：
ISR到底指的是什麼東西？
既然大家已經知道了Partiton的多副本同步數據的機制了，那麼就可以來看看ISR是什麼了。
ISR全稱是“In-Sync Replicas”，也就是保持同步的副本，他的含義就是，跟Leader始終保持同步的Follower有哪些。大家可以想一下 ，如果說某個Follower所在的Broker因爲JVM FullGC之類的問題，導致自己卡頓了，無法及時從Leader拉取同步數據，那麼是不是會導致Follower的數據比Leader要落後很多？所以這個時候，就意味着Follower已經跟Leader不再處於同步的關係了。但是隻要Follower一直及時從Leader同步數據，就可以保證他們是處於同步的關係的。所以每個Partition都有一個ISR，這個ISR裏一定會有Leader自己，因爲Leader肯定數據是最新的，然後就是那些跟Leader保持同步的Follower，也會在ISR裏。
acks參數的含義
鋪墊了那麼多的東西，最後終於可以進入主題來聊一下acks參數的含義了。
如果大家沒看明白前面的那些副本機制、同步機制、ISR機制，那麼就無法充分的理解acks參數的含義，這個參數實際上決定了很多重要的東西。
首先這個acks參數，是在KafkaProducer，也就是生產者客戶端裏設置的，也就是說，你往kafka寫數據的時候，就可以來設置這個acks參數。然後這個參數實際上有三種常見的值可以設置，分別是：0、1 和 all。
第一種選擇是把acks參數設置爲0
意思就是我的KafkaProducer在客戶端，只要把消息發送出去，不管那條數據有沒有落到Partition Leader磁盤上，我就不管他了，直接就認爲這個消息發送成功了。
如果你採用這種設置的話，那麼你必須注意的一點是，可能你發送出去的消息還在半路。結果呢，Partition Leader所在Broker就直接掛了，然後結果你的客戶端還認爲消息發送成功了，此時就會導致這條消息就丟失了。
第二種選擇是設置 acks = 1
意思就是說只要Partition Leader接收到消息而且寫入本地磁盤了，就認爲成功了，不管他其他的Follower有沒有同步過去這條消息了。這種設置其實是kafka默認的設置，大家請注意，劃重點！這是默認的設置
也就是說，默認情況下，你要是不管acks這個參數，只要Partition Leader寫成功就算成功。但是這裏有一個問題，萬一Partition Leader剛剛接收到消息，Follower還沒來得及同步過去，結果Leader所在的broker宕機了，此時也會導致這條消息丟失，因爲客戶端已經認爲發送成功了。
最後一種情況，就是設置acks=all
這個意思就是說，Partition Leader接收到消息之後，還必須要求ISR列表裏跟Leader保持同步的那些Follower都要把消息同步過去，才能認爲這條消息是寫入成功了。
如果說Partition Leader剛接收到了消息，但是結果Follower沒有收到消息，此時Leader宕機了，那麼客戶端會感知到這個消息沒發送成功，他會重試再次發送消息過去。此時可能Partition 2的Follower變成Leader了，此時ISR列表裏只有最新的這個Follower轉變成的Leader了，那麼只要這個新的Leader接收消息就算成功了。
最後的思考
acks=all 就可以代表數據一定不會丟失了嗎？
當然不是，如果你的Partition只有一個副本，也就是一個Leader，任何Follower都沒有，你認爲acks=all有用嗎？當然沒用了，因爲ISR裏就一個Leader，他接收完消息後宕機，也會導致數據丟失。所以說，這個acks=all，必須跟ISR列表裏至少有2個以上的副本配合使用，起碼是有一個Leader和一個Follower纔可以。這樣才能保證說寫一條數據過去，一定是2個以上的副本都收到了纔算是成功，此時任何一個副本宕機，不會導致數據丟失。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
考慮一千次，不如去做一次；猶豫一萬次，不如實踐一次；華麗的跌倒，勝過無謂的彷徨，將來的你，一定會感謝現在奮鬥的你。歡迎大家加入大數據交流羣：725967421 一起交流，一起進步！！
------------------------------------------------------------------------------------------------------------------------------------------------------------------------