replica(KAFKA中的Replica是什么)

【能否說下Replica的主從設計?】

冗余,可以理解為一個動作,就是把一份數據多拷貝了幾份出來。

而拷貝出來的數據我們就稱之為副本,這也是Replica的真正含義,那么多副本之間就必然存在著數據同步的問題:

也就是不同副本之間,以哪個副本的數據為準,如何保持數據一致這兩個主要問題。

因此,副本之間就有了主從的一個設計,負責提供讀寫的副本是leader,而其余的副本稱之為follower,follower副本只需要從leader副本那里一直拉取數據就好了,正常情況下不需要提供讀寫。

看起來是這個樣子的:

【能否說下Replica解決了什么問題?】

首先我們要明白一點——某個Partition的數據副本,都是分布在不同的broker上的,也就是說是分布在不同機器上的,那么顯而易見,Replica是為了解決單點問題而設計的。

我們再考慮下會存在哪些單點問題?

1、當我們生產消息的時候,如果數據只寫入了一個broker就返回了,那么一旦那個broker掛了,或者所在機器宕機了,是不是可能造成我剛才寫入的消息就丟失了?

2、我們生產/消費都只針對leader-replica進行,那么是不是一旦leader所在的broker掛了,或者所在機器宕機了,就無法進行生產消費了?

以上就是主要存在的兩個問題,在引入副本的設計后,解決這兩個問題就很簡單了:

1、由于存在多副本,因此我們可以設置寫入所有副本后,才算寫入消息成功;那么數據就會分散到多個節點上,從而避免了單點問題。這就是之前提到的實現了消息的高可靠。

2、由于存在多個副本,并且副本之間的數據一直在同步,一旦leader所在節點出現問題,那么我們就可以進行主備切換,讓某個follower成為新的leader來繼續提供讀寫,從而避免了整個服務不可用了。這就是之前提到的實現服務的高可用。

感謝各位的閱讀,以上就是“ KAFKA中的Replica是什么”的內容了,經過本文的學習后,相信大家對 KAFKA中的Replica是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是本站,小編將為大家推送更多相關知識點的文章,歡迎關注!