Kafka是靠什么機(jī)制保持高可靠及高可用的

今天就跟大家聊聊有關(guān)Kafka是靠什么機(jī)制保持高可靠及高可用的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

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

下面對 Kafka 的 Acks 參數(shù)的分析，以及背后的原理。

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

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

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

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

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

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

多副本冗余的高可用機(jī)制

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

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

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

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

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

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

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

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

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

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

如下圖所示：

ISR 到底指的是什么東西?

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

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

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

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

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

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

Acks 參數(shù)的含義

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

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

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

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

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

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

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

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

這種設(shè)置其實是 Kafka 默認(rèn)的設(shè)置，大家請注意，劃重點!這是默認(rèn)的設(shè)置。

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

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

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

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

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

思考

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

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

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

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

看完上述內(nèi)容，你們對Kafka是靠什么機(jī)制保持高可靠及高可用的有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。