消費端出現offset重置為latest, earliest現象，類似log：
(org.apache.kafka.clients.consumer.internals.Fetcher.handleFetchResponse:595) - Fetch offset 2261734 is out of range, resetting offset
原因：該consumer消費的topic的leader和followers的狀態不一致時，發生leader切換，會發生offset out of range，此時consumer進行消費時發現offset非法，會進行offset重置
在測試環境中創建一個topic test，3個分區，2個副本，broker 1為leader，broker 2為follower。
寫入一些數據消費端進行正常消費，消費至最新狀態A處之后，將test的follower的broker2停掉，繼續向test寫入數據，並讓consumer再次消費至最新狀態B處。
此時停掉的follower broker 2的狀態已和leader broker 1的狀態不一樣，已滯后leader的狀態。
現在將follower broker 2啟動，此時follower和leader的狀態不一樣，follower需要和leader進行同步，但當follower與leader未同步成功之前將leader broker 1停掉，然后follower broker 2經過leader的選舉機制被迫選為leader(unclean.leader.election.enable為true時，選擇第一個啟動的副本為leader)，在被選舉為leader之前broker 2的狀態並沒有和broker 1的狀態一致，也就是說broker 2上的LEO並沒有同步到B處，而broker 2被選舉為了leader，此時producer繼續向topic中寫數據，寫入之后consumer會進行消費，consumer需要消費的offset的B，而broker 2的LEO並沒有同步到B處，此時就發生了out of ranger，offset被重置。
優化方案
針對以上情況我們進行了一下修改：
1. 將topic的副本數設置為3(原先為2)，減少ISR列表只有一個leader的幾率
2. 調整min.insync.replicas為2(默認是1)，此參數的意思是當ISR中的個數小於此值時，producer無法寫入數據，會拋出異常。此參數還需要結合acks來使用，需要將acks設置為all或者-1(flume中kafkaChannel默認是all)。
3. 調整unclean.leader.election.enable參數為false(默認為true)，此參數標識當ISR中沒有副本時，選舉最早啟動的broker為leader。 版本0.11中已經修改默認值為false
4. 集群因為維護需要重啟時，先停掉一台broker，然后重啟該broker，等到該broker已加入到ISR中之后，再對其它broker進行如上操作，切勿單個broker依次重啟。