消息隊列之kafka(HA)
阿新 • • 發佈:2018-12-31
art 圖片 ava png ext 元數據 存儲 zookeep ilove 1. kafka的HA
解決的問題:Kafka的HA就是在數據層面上,即丟失一份數據,Consumer仍然可以正常消費(也表示一個broker宕機了,其上面的數據不會丟失)。
解決的方案:使用replication(副本,對同一個數據進行數據備份)。其中副本之間有主副本和從副本之分(由zookeeper選出),每一個broker都會存儲一些主副本,保證kafka集群的負載均衡。 - 在進行寫數據的時候,首先向leader寫入數據(主副本)
- 其他的broker(follower)到leader中fetch數據(從副本)
- 數據抓取完成後,會向leader返回(ack)信息
解釋 :在leader中會維護一個ISR(同步副本的列表),列表中存放的是所有的有效的follwer, 在這個列表中如果follower的數據和leader的數據落後太多的話(默認是4000條數據)或者一定時間沒有向leader發送fetch請求(默認是10秒),這時候會自動的將這個follwer剔除這個ISR列表中,在這個ISR列表中,每一個follower進行fetch完成數據,就會向leader發送數據,最終leader如果接受到所有的follower反饋,然後向producer進行反饋,發送ACK。
其中ACK表示Producer寫入數據的返回級別:
(1)zookeeper在kafka中的作用:
- Zookeeper幫助kafka集群運行:存儲一些元數據,還會幫助kafka集群進行管理(選主)
- 存儲關於消費者消費了哪些topic到那個進度的數據。
(2)kafka HA解決的問題:
存在的問題:kafka在0.8以前的版本中,並不提供high available機制,一旦一個或者多個broker宕機,則宕機期間其上的partition都無法繼續提供服務。若該broker永遠不能回復或磁盤故障,則其上數據丟失。但是對於分布式來說尤其是集群上升到一定規模,一臺或者多臺機器宕機的可能性大大提高,對failover要求非常高。因此kafka開始在0.8版本以後提供高可用機制。
解決的方案:使用replication(副本,對同一個數據進行數據備份)。其中副本之間有主副本和從副本之分(由zookeeper選出),每一個broker都會存儲一些主副本,保證kafka集群的負載均衡。
(3)kafka HA寫數據的流程:
- 使用zookeeper給多個副本的broker進行選主,選出一個leader
這個leader相當於zookeeper中的一個臨時節點,如果leader宕機之後,zookeeper會再次選主,如果ISR列表中所有的follower都宕機了,此時會等待,等待ISR列表有一個follower重新可以使用的時候,這是就將這個follower變成leader。(ISR是kafka在zookeeper中維護的一個可使用的集群節點列表)
- 其他的broker(follower)到leader中fetch數據(從副本)
- 數據抓取完成後,會向leader返回(ack)信息
解釋 :在leader中會維護一個ISR(同步副本的列表),列表中存放的是所有的有效的follwer, 在這個列表中如果follower的數據和leader的數據落後太多的話(默認是4000條數據)或者一定時間沒有向leader發送fetch請求(默認是10秒),這時候會自動的將這個follwer剔除這個ISR列表中,在這個ISR列表中,每一個follower進行fetch完成數據,就會向leader發送數據,最終leader如果接受到所有的follower反饋,然後向producer進行反饋,發送ACK。
0 表示只要producer發送數據,就表示寫數據成功
1 表示只要leader寫入成功,就表示寫數據成功
all /-1 表示所有的副本寫成功,才認為數據寫入成功
消息隊列之kafka(HA)