iT邦幫忙

2021 iThome 鐵人賽

DAY 29
0
Modern Web

『卡夫卡的藏書閣』- 程序猿必須懂的Kafka開發與實作系列 第 29

卡夫卡的藏書閣【Book29】- Kafka - MirroMaker 2

“I need solitude for my writing; not 'like a hermit' - that wouldn't be enough - but like a dead man.”
― Franz Kafka


MirrorMaker 也就是所謂的跨叢集資料鏡射,通常有幾種使用場景,像是災害備援系統,將整個叢集複製放置於另外一個地方,如果遇到意外事件導致叢集失敗,可以立刻將資料來源切換到備援系統,而這種跨叢集資料會遇到幾個問題,延遲性的問題,叢集間的傳輸速率會因為網路間的距離跟網路傳導次數而增加、成本的問題,因為無論是企業自建機房或是在雲端上建構,頻寬的成本都是十分驚人的,必須考慮到是否有必要性

除了 MirrorMaker 之外,也有 Uber 的 uReplicator,和 Confluent 的 Replicator,Uber當年在使用 MirroMaker 遇到了不少問題,隨著他們業務增長、主題跟分區也逐漸增加,在消費者重新平衡的花費時間增加到過長,導致跟同步的資料堆積,需要花費很多時間去消耗,會導致目標叢集的消費者的消費延遲,另外就是新增主題有相當的困難性,因為新增主題會導致消費者的再平衡,從而導致剛剛的問題又再度發生,Uber 的 uReplicator 就是藉由 Apache 的 Helix 元件來解決這個問題

Confluent 的 Replicator 主要是用來解決叢集設定的問題,常常會發生修改本地叢集,卻漏改目標叢集、區域叢集,還有就是管理多個叢集,通常管理一對一的叢集設定檔就是相當困難的,因此 Replicator 可以透過 Kafka Connect 去幫忙管理設定檔


上一篇
卡夫卡的藏書閣【Book28】- Kafka - MirroMaker
下一篇
卡夫卡的藏書閣【Book30】- Kafka - Sum up
系列文
『卡夫卡的藏書閣』- 程序猿必須懂的Kafka開發與實作30

尚未有邦友留言

立即登入留言