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

平安銀行一面:Kafka ISR的原理是什么?

開發(fā)
ISR機(jī)制是 Kafka實(shí)現(xiàn)高可靠性和高可用性的一個重要機(jī)制,它的出現(xiàn)大大提高了 Kafka的實(shí)用性,使其成為了大數(shù)據(jù)領(lǐng)域廣泛使用的消息隊(duì)列系統(tǒng)。

Kafka 的高可用性和高可靠性與它的 ISR機(jī)制密切相關(guān)。那么,什么是 ISR?它是如何工作的?這篇文章,我們來詳解 Kafka 的 ISR 機(jī)制。

什么是 ISR機(jī)制?

ISR 的全稱叫做In-Sync Replicas(同步副本集),ISR 動態(tài)維護(hù)了一個和 Leader 副本保持同步副本集合,ISR 中的副本全部都和 Leader 的數(shù)據(jù)保持同步。

ISR 機(jī)制通過副本冗余機(jī)制,提供了 kafka 消息的高可靠性,做到故障轉(zhuǎn)移,保障服務(wù)的可用性。ISR 平衡了主從架構(gòu)下,復(fù)制方案的選擇(同步 / 異步 / 少數(shù)服從多數(shù)),讓使用者根據(jù)參數(shù)自行選擇。

ISR的作用

ISR的作用主要體現(xiàn)在以下幾個方面:

1.生產(chǎn)消息時的ACK確認(rèn)機(jī)制

當(dāng)我們生產(chǎn)消息的時候,到底要寫入多少副本才能算成功呢?通過 ISR 就可以知曉了哪些 follower 與 Leader 保持著同步,在寫入消息的時候,設(shè)置寫入處于 ISR 中所有的副本才算成功。Kafka提供了以下幾種ACK確認(rèn)機(jī)制:

(1) acks=0

生產(chǎn)者不等待服務(wù)器的確認(rèn),消息發(fā)送后即認(rèn)為成功,不管消息是否真正寫入 Kafka,這種方式效率最高,但可靠性最低,數(shù)據(jù)可能存在丟失。

(2) acks=1

生產(chǎn)者會等待來自 Leader分區(qū)的確認(rèn)。Leader分區(qū)接收到消息并寫入本地日志后即返回確認(rèn)。這種方式在 Leader分區(qū)可用時可靠,但如果 Leader分區(qū)發(fā)生故障,可能會丟失數(shù)據(jù)。從 Kafka 2.0 開始,默認(rèn)值是 acks=1

(3) acks=all(或-1)

生產(chǎn)者等待所有 ISR(In-Sync Replica,同步副本)分區(qū)的確認(rèn)。只有當(dāng)消息被寫入所有同步副本后才返回確認(rèn),這種方式最可靠,但性能較低。

2.Leader選舉

當(dāng) Leader 掛了之后,我們應(yīng)該選擇哪個 follower 來成為新的 Leader 呢?從 ISR 中選擇對應(yīng)的 follower 成為新的 Leader。

3.最小 ISR副本數(shù)配置

Kafka提供了 min.insync.replicas 參數(shù)配置,這個參數(shù)可以配置最少 ISR 中需要多少個副本,才能繼續(xù)提供寫服務(wù)。如果設(shè)置為 2,一旦 ISR 中的個數(shù)小于 2,那么就不再提供寫服務(wù),犧牲一定的可用性,來保障這種高可靠的場景需求。

ISR的原理

ISR機(jī)制的實(shí)現(xiàn)原理如下:

(1) Leader維護(hù)ISR

Leader負(fù)責(zé)維護(hù)ISR,當(dāng)一個Follower趕上了Leader的進(jìn)度,Leader會把它加入到ISR中;當(dāng)一個Follower長時間未趕上Leader,或者主動退出同步,Leader會把它從ISR中移除,變成OSR(Out-of-Sync Replicas)。

(2) 生產(chǎn)者發(fā)送消息

生產(chǎn)者發(fā)送消息給Leader,Leader會把消息append到本地log,并且復(fù)制給ISR中的所有Follower。

(3) 消息提交

當(dāng)ISR中的所有Follower都完成了復(fù)制,Leader會更新HW(High Watermark,最高提交偏移量),此時消息才算真正提交。

(4) 消費(fèi)者消費(fèi)消息

消費(fèi)者只能消費(fèi)提交的消息,即位于HW之前的消息。

(5) Follower同步數(shù)據(jù)

Follower定期主動從Leader拉取數(shù)據(jù),保持與Leader的同步。當(dāng)Follower死機(jī)或長時間未同步時,會被從ISR中移除。

(6) Leader選舉

當(dāng)Leader所在的broker失效時,ISR中的其他Follower會選出一個新的Leader。選舉規(guī)則是:選擇ISR中最新的Follower。

實(shí)例分析

為了更好地理解 ISR機(jī)制,我們通過一個示例來講解。

假設(shè)一個 Kafka 集群中有一個 Topic test,該 Topic 有一個分區(qū) partition-0,該分區(qū)有 3 個副本,分別在 Broker 1、Broker 2 和 Broker 3 上。

  • 在初始狀態(tài)時:Leader 副本:Broker 1 Follower 副本:Broker 2, Broker 3 所有的副本都工作良好,所以 ISR 集合為:[Broker 1, Broker 2, Broker 3]
  • 假如 Broker 2 失效:Broker 2 從 ISR 集合中移除,因此,ISR 集合變成了:[Broker 1, Broker 3]
  • 接著 Broker 1 也失效了:Broker 3 被選為新的 Leader,SR 集合變成了:[Broker 3]
  • 再然后,Broker 2 恢復(fù):Broker 2 開始從 Broker 3 復(fù)制數(shù)據(jù),Broker 2 追上 Broker 3 后,重新加入 ISR 集合,因此,ISR 集合變成了:[Broker 2, Broker 3]

ISR的優(yōu)缺點(diǎn)

ISR機(jī)制的優(yōu)點(diǎn):

  • 提供了消息的高可靠性,即使部分副本失效,只要ISR中還有副本存活,消息就不會丟失。
  • 支持故障轉(zhuǎn)移,當(dāng) Leader失效時,ISR中的Follower可以順利接替成為新的 Leader,提高了系統(tǒng)的可用性。
  • 通過ACK機(jī)制,生產(chǎn)者可以根據(jù)自己的需求,在可靠性和吞吐量之間進(jìn)行權(quán)衡。

ISR機(jī)制的缺點(diǎn):

  • 同步復(fù)制會增加消息發(fā)送的延遲,因?yàn)樯a(chǎn)者需要等待所有ISR中的副本完成復(fù)制。
  • ISR中的副本越多,消息發(fā)送的延遲就越高。
  • ISR中的副本數(shù)量受限于min.insync.replicas參數(shù),如果副本數(shù)量低于該值,就無法提供寫服務(wù),會降低系統(tǒng)的可用性。

總結(jié)

ISR機(jī)制是 Kafka實(shí)現(xiàn)高可靠性和高可用性的關(guān)鍵所在,它通過動態(tài)維護(hù)一個和Leader保持同步的副本集合,為消息的可靠性提供了保證。同時,ISR機(jī)制還支持故障轉(zhuǎn)移,當(dāng) Leader失效時,ISR中的 Follower可以順利接替成為新的 Leader。

不過,ISR機(jī)制也存在一些缺點(diǎn),比如會增加消息發(fā)送的延遲,并且ISR中的副本數(shù)量受限于 min.insync.replicas參數(shù)。因此,在使用ISR機(jī)制時,需要根據(jù)實(shí)際的業(yè)務(wù)需求,在可靠性、可用性和吞吐量之間進(jìn)行權(quán)衡。

總的來說,ISR機(jī)制是 Kafka實(shí)現(xiàn)高可靠性和高可用性的一個重要機(jī)制,它的出現(xiàn)大大提高了 Kafka的實(shí)用性,使其成為了大數(shù)據(jù)領(lǐng)域廣泛使用的消息隊(duì)列系統(tǒng)。


責(zé)任編輯:趙寧寧 來源: 猿java
相關(guān)推薦

2025-03-24 09:10:00

Spring注解代碼

2024-11-26 08:52:34

SQL優(yōu)化Kafka

2024-10-22 15:25:20

2024-10-30 16:12:14

2024-09-19 08:51:01

HTTP解密截取

2024-10-15 10:59:18

Spring MVCJava開發(fā)

2022-05-11 22:15:51

云計(jì)算云平臺

2025-03-24 07:35:00

開發(fā)注解Spring

2009-07-30 14:38:36

云計(jì)算

2020-09-19 17:46:20

React Hooks開發(fā)函數(shù)

2025-03-19 08:00:00

@CacheableSpring注解

2011-12-23 09:43:15

開源開放

2011-12-22 20:53:40

Android

2024-05-15 16:41:57

進(jìn)程IO文件

2024-09-24 10:11:43

2022-12-13 18:09:25

連接狀態(tài)客戶端

2012-12-19 09:04:29

2025-04-01 08:40:00

HTTPRPC開發(fā)

2024-09-04 15:17:23

2024-11-11 16:40:04

點(diǎn)贊
收藏

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