本文將圍繞kafka的可用性展開,包含數據同步、順序保證,以及生產者消費者爲了保證數據同步可採用的高可用配置。是自己的一些心得。
文章關鍵詞:
- 不完全的首領選舉
- 丟數據的可能原因
- 發送消息中,kafka可重試錯誤和不可重試錯誤
- 保證順序
- producer consumer的可靠性配置
不完全的首領選舉
場景:首領掛了,但是follower沒有同步
針對該場景可以採取兩種方式:
- 等首領好(可用性差,保證不丟數據)
- 不等首領,選擇未同步副本做首領(可用性高,但是丟了與老首領未同步完的中間數據)
可以通過unclean.leader.election.enable設置,爲true對應方式二,false對應方式一
附:unclean可能會引發的問題:consumer “Fetch offset xxxx is out of range, resetting offset”
丟數據的可能原因
上面提到了unclean.leader.election.enable=true會導致數據丟失,下面兩種情況也會導致數據丟失:
- producer生產者角色acks參數影響,可能會導致問題,場景:acks=1,發送給leader成功時,沒有同步給replicas時leader掛了。在producer層面則丟失了這條消息
- acks=all時,發送時返回了“首領不可用”,但是producer客戶端沒有重試機制,或者好的處理方式,還是會丟
可重試錯誤和不可重試錯誤
上面的第二點,數據在沒有好的重試機制也會丟失,其實對於kafka生產者來說是自帶重試機制的,可以通過retries retry.backoff.ms兩個參數來控制,這裏不做贅述,在此羅列一下producer可重試和非可重試的錯誤。
kafka可重試錯誤(重試可能會解決)
- LeaderNotAvailable (通過retries retry.backoff.ms參數,自帶重試)
kafka不可重試錯誤(重試不會解決)
- 消息大小錯誤、認證錯誤、序列化錯誤、佔用內存上限(需要自寫重試)
如何保證順序
這裏是指生產者在生產層面的消息入broker順序。
關鍵詞參數:max.in.flight.requests.per.connection retries retry.backoff.ms offset
不少情況下我們需要保證一個操作的順序性,比如交易類的操作,先存錢和先花錢。
如果把retries設置爲>0 max.in.flight.requests.per.connection>1 ,這時如果第一批的消息寫失敗,第二批次寫成功,然後第一批次再次重試寫成功,此時順序就出現了問題(第二批次在第一批次前寫入了,比如先花錢後存錢)。
解決方案:
- 保證有序是很關鍵,但寫入成功更爲關鍵,所以不建議把retries=0,可以設置max.in.flight.requests.per.connection=1來保證順序
附:如果生產者能保證順序了,希望在消費端保證順序,可以考慮把offset存於持久層來解決問題,即消息bean入庫時一併把offset入庫,用offset決定順序。注:這裏沒有實踐過只是覺得可行。
消費者的可靠性配置
關於消費者可靠性參數整理如下:
- group.id
- auoto.offset.reset
- enable.auto.commit
- auto.commit.interval.ms
如果不瞭解具體含義請 http://kafka.apache.org/documentation/#consumerconfigs。
感謝觀看~