面試大廠時，一旦簡歷上寫了 Kafka，幾乎必然會被問到一個問題：說說 Acks 參數(shù)對消息持久化的影響?

這個 Acks 參數(shù)在 Kafka 的使用中，是非常核心以及關鍵的一個參數(shù)，決定了很多東西。

所以無論是為了面試還是實際項目使用，大家都值得看一下這篇文章對 Kafka 的 Acks 參數(shù)的分析，以及背后的原理。

如何保證宕機的時候數(shù)據(jù)不丟失?

如果想理解這個 Acks 參數(shù)的含義，首先就得搞明白 Kafka 的高可用架構(gòu)原理。

比如下面的圖里就是表明了對于每一個 Topic，我們都可以設置它包含幾個 Partition，每個 Partition 負責存儲這個 Topic 一部分的數(shù)據(jù)。

然后 Kafka 的 Broker 集群中，每臺機器上都存儲了一些 Partition，也就存放了 Topic 的一部分數(shù)據(jù)，這樣就實現(xiàn)了 Topic 的數(shù)據(jù)分布式存儲在一個 Broker 集群上。

 

但是有一個問題，萬一一個 Kafka Broker 宕機了，此時上面存儲的數(shù)據(jù)不就丟失了嗎?

沒錯，這就是一個比較大的問題了，分布式系統(tǒng)的數(shù)據(jù)丟失問題，是它首先必須要解決的，一旦說任何一臺機器宕機，此時就會導致數(shù)據(jù)的丟失。

多副本冗余的高可用機制

所以如果大家去分析任何一個分布式系統(tǒng)的原理，比如說 Zookeeper、Kafka、Redis Cluster、Elasticsearch、HDFS，等等。

其實它們都有自己內(nèi)部的一套多副本冗余的機制，多副本冗余幾乎是現(xiàn)在任何一個優(yōu)秀的分布式系統(tǒng)都一般要具備的功能。

在 Kafka 集群中，每個 Partition 都有多個副本，其中一個副本叫做 Leader，其他的副本叫做 Follower，如下圖：

 

如上圖所示，假設一個 Topic 拆分為了 3 個 Partition，分別是 Partition0，Partiton1，Partition2，此時每個 Partition 都有 2 個副本。

比如 Partition0 有一個副本是 Leader，另外一個副本是 Follower，Leader 和 Follower 兩個副本是分布在不同機器上的。

這樣的多副本冗余機制，可以保證任何一臺機器掛掉，都不會導致數(shù)據(jù)徹底丟失，因為起碼還是有副本在別的機器上的。

多副本之間數(shù)據(jù)如何同步?

接著我們就來看看多個副本之間數(shù)據(jù)是如何同步的?其實任何一個 Partition，只有 Leader 是對外提供讀寫服務的。

也就是說，如果有一個客戶端往一個 Partition 寫入數(shù)據(jù)，此時一般就是寫入這個 Partition 的 Leader 副本。

然后 Leader 副本接收到數(shù)據(jù)之后，F(xiàn)ollower 副本會不停的給它發(fā)送請求嘗試去拉取***的數(shù)據(jù)，拉取到自己本地后，寫入磁盤中。

如下圖所示：

 

ISR 到底指的是什么東西?

既然大家已經(jīng)知道了 Partiton 的多副本同步數(shù)據(jù)的機制了，那么就可以來看看 ISR 是什么了。

ISR 全稱是“In-Sync Replicas”，也就是保持同步的副本，它的含義就是，跟 Leader 始終保持同步的 Follower 有哪些。

大家可以想一下 ，如果說某個 Follower 所在的 Broker 因為 JVM FullGC 之類的問題，導致自己卡頓了，無法及時從 Leader 拉取同步數(shù)據(jù)，那么是不是會導致 Follower 的數(shù)據(jù)比 Leader 要落后很多?

所以這個時候，就意味著 Follower 已經(jīng)跟 Leader 不再處于同步的關系了。

但是只要 Follower 一直及時從 Leader 同步數(shù)據(jù)，就可以保證它們是處于同步的關系的。

所以每個 Partition 都有一個 ISR，這個 ISR 里一定會有 Leader 自己，因為 Leader 肯定數(shù)據(jù)是***的，然后就是那些跟 Leader 保持同步的 Follower，也會在 ISR 里。

Acks 參數(shù)的含義

鋪墊了那么多的東西，***終于可以進入主題來聊一下 Acks 參數(shù)的含義了。

如果大家沒看明白前面的那些副本機制、同步機制、ISR 機制，那么就無法充分的理解 Acks 參數(shù)的含義，這個參數(shù)實際上決定了很多重要的東西。

首先這個 Acks 參數(shù)，是在 Kafka Producer，也就是生產(chǎn)者客戶端里設置的。

也就是說，你往 Kafka 寫數(shù)據(jù)的時候，就可以來設置這個 Acks 參數(shù)。然后這個參數(shù)實際上有三種常見的值可以設置，分別是：0、1 和 all。

***種選擇是把 Acks 參數(shù)設置為 0，意思就是我的 Kafka Producer 在客戶端，只要把消息發(fā)送出去，不管那條數(shù)據(jù)有沒有在哪怕 Partition Leader 上落到磁盤，我就不管它了，直接就認為這個消息發(fā)送成功了。

如果你采用這種設置的話，那么你必須注意的一點是，可能你發(fā)送出去的消息還在半路。

結(jié)果呢，Partition Leader 所在 Broker 就直接掛了，然后結(jié)果你的客戶端還認為消息發(fā)送成功了，此時就會導致這條消息就丟失了。

 

第二種選擇是設置 Acks = 1，意思就是說只要 Partition Leader 接收到消息而且寫入本地磁盤了，就認為成功了，不管它其他的 Follower 有沒有同步過去這條消息了。

這種設置其實是 Kafka 默認的設置，大家請注意，劃重點!這是默認的設置。

也就是說，默認情況下，你要是不管 Acks 這個參數(shù)，只要 Partition Leader 寫成功就算成功。

但是這里有一個問題，萬一 Partition Leader 剛剛接收到消息，F(xiàn)ollower 還沒來得及同步過去，結(jié)果 Leader 所在的 Broker 宕機了，此時也會導致這條消息丟失，因為人家客戶端已經(jīng)認為發(fā)送成功了。

 

***一種情況，就是設置 Acks=all，這個意思就是說，Partition Leader 接收到消息之后，還必須要求 ISR 列表里跟 Leader 保持同步的那些 Follower 都要把消息同步過去，才能認為這條消息是寫入成功了。

如果說 Partition Leader 剛接收到了消息，但是結(jié)果 Follower 沒有收到消息，此時 Leader 宕機了，那么客戶端會感知到這個消息沒發(fā)送成功，他會重試再次發(fā)送消息過去。

此時可能 Partition2 的 Follower 變成 Leader 了，此時 ISR 列表里只有***的這個 Follower 轉(zhuǎn)變成的 Leader 了，那么只要這個新的 Leader 接收消息就算成功了。

 

***的思考

Acks=all 就可以代表數(shù)據(jù)一定不會丟失了嗎?當然不是，如果你的 Partition 只有一個副本，也就是一個 Leader，任何 Follower 都沒有，你認為 acks=all 有用嗎?

當然沒用了，因為 ISR 里就一個 Leader，它接收完消息后宕機，也會導致數(shù)據(jù)丟失。

所以說，這個 Acks=all，必須跟 ISR 列表里至少有 2 個以上的副本配合使用，起碼是有一個 Leader 和一個 Follower 才可以。

這樣才能保證說寫一條數(shù)據(jù)過去，一定是 2 個以上的副本都收到了才算是成功，此時任何一個副本宕機，不會導致數(shù)據(jù)丟失。

所以希望大家把這篇文章好好理解一下，對大家出去面試，或者工作中用 Kafka 都是很好的一個幫助。

作者：中華石杉

中華石杉：十余年 BAT 架構(gòu)經(jīng)驗，一線互聯(lián)網(wǎng)公司技術總監(jiān)。帶領上百人團隊開發(fā)過多個億級流量高并發(fā)系統(tǒng)。現(xiàn)將多年工作中積累下的研究手稿、經(jīng)驗總結(jié)整理成文，傾囊相授。微信公眾號：石杉的架構(gòu)筆記(ID：shishan100)。