自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

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

開發(fā) 架構(gòu) 開發(fā)工具 Kafka
面試大廠時(shí),一旦簡歷上寫了 Kafka,幾乎必然會被問到一個(gè)問題:說說 Acks 參數(shù)對消息持久化的影響?

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

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

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

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

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

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

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

 

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

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

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

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

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

在 Kafka 集群中,每個(gè) Partition 都有多個(gè)副本,其中一個(gè)副本叫做 Leader,其他的副本叫做 Follower,如下圖:

 

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

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

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

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

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

也就是說,如果有一個(gè)客戶端往一個(gè) Partition 寫入數(shù)據(jù),此時(shí)一般就是寫入這個(gè) 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 有哪些。

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

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

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

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

Acks 參數(shù)的含義

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

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

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

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

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

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

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

 

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

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

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

但是這里有一個(gè)問題,萬一 Partition Leader 剛剛接收到消息,F(xiàn)ollower 還沒來得及同步過去,結(jié)果 Leader 所在的 Broker 宕機(jī)了,此時(shí)也會導(dǎo)致這條消息丟失,因?yàn)槿思铱蛻舳艘呀?jīng)認(rèn)為發(fā)送成功了。

 

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

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

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

 

***的思考

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

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

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

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

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

作者:中華石杉

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

 

責(zé)任編輯:武曉燕 來源: 石杉的架構(gòu)筆記
相關(guān)推薦

2013-09-09 09:39:02

云數(shù)據(jù)庫京東云

2022-07-14 18:21:06

高基數(shù)工業(yè)物聯(lián)網(wǎng)數(shù)據(jù)庫

2021-04-06 20:46:50

Kafka高可用Leader

2023-11-12 00:10:07

Redis高可用

2023-05-08 14:56:00

Kafka高可靠高性能

2018-05-07 10:20:38

Kafka存儲機(jī)制

2024-07-25 08:39:48

2023-11-07 15:11:46

Kafka技巧

2021-06-29 10:18:07

Kafka宕機(jī)系統(tǒng)

2024-05-29 07:50:41

2017-11-13 11:07:32

Nginx搭建高可用

2020-10-28 07:10:07

Nginx高可用高并發(fā)

2019-11-13 10:31:49

Kafka架構(gòu)高可用

2019-12-11 10:14:23

Kafka吞吐量架構(gòu)

2024-01-15 10:57:05

2020-11-26 09:38:19

分布式架構(gòu)系統(tǒng)

2021-09-23 12:14:50

Redis分布式優(yōu)化

2018-02-27 14:30:17

2025-01-15 10:53:54

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號