Kafka是靠什么機制保持高可靠及高可用的

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

這個 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 參數，是在 Kafka Producer，也就是生產者客戶端里設置的。

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

***種選擇是把 Acks 參數設置為 0，意思就是我的 Kafka Producer 在客戶端，只要把消息發送出去，不管那條數據有沒有在哪怕  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  宕機了，那么客戶端會感知到這個消息沒發送成功，他會重試再次發送消息過去。

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

思考

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

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

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

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

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