本文將圍繞kafka的可用性展開，包含broker數據同步、順序保證，以及生產者消費者爲了保證數據同步可採用的高可用配置。是自己的一些心得。
文章關鍵詞：
- 不完全的首領選舉
- 丟數據的可能原因
- 發送消息中，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。
感謝觀看~