如何提高Kafka可靠性是一個可以長篇大論的主題。很多初學者會簡單的認為將客戶端引數acks設定為-1即可保證Kafka的可靠性，顯然這是很片面的觀點。就可靠性本身而言，它並不是一個可以用“是”或者“否”來衡量的一個指標，而一般是用幾個9來衡量。就引數方面而言，與Kafka可靠性相關的引數不止acks這一個，比如retries、replication.factor、min.insync.replicas、unclean.leader.election.enable等等，某些引數還要級聯配置。

本文主要闡述的是Kafka可靠性相關引數中的一個，即unclean.leader.election.enable。隨著Kafka版本的變更，有的引數消失，也有的引數被加入進來，而傳承下來的引數一般都不太會修改既定的預設值，而unclean.leader.election.enable引數卻是其中的一個反例。從Kafka 0.11.0.0版本開始unclean.leader.election.enable引數的預設值由原來的true改為false，這個引數背後到底意味著什麼，Kafka的設計者處於什麼原因要修改這個預設值？ 

參考上圖，某種狀態下，follower2副本落後leader副本很多，並且也不在leader副本和follower1副本所在的ISR（In-Sync Replicas）集合之中。follower2副本正在努力的追趕leader副本以求迅速同步，並且能夠加入到ISR中。但是很不幸的是，此時ISR中的所有副本都突然下線，情形如下圖所示： 

此時follower2副本還在，就會進行新的選舉，不過在選舉之前首先要判斷unclean.leader.election.enable引數的值。如果unclean.leader.election.enable引數的值為false，那麼就意味著非ISR中的副本不能夠參與選舉，此時無法進行新的選舉，此時整個分割槽處於不可用狀態。如果unclean.leader.election.enable引數的值為true，那麼可以從非ISR集合中選舉follower副本稱為新的leader。 

我們進一步考慮unclean.leader.election.enable引數為true的情況，在上面的這種情形中follower2副本就順其自然的稱為了新的leader。隨著時間的推進，新的leader副本從客戶端收到了新的訊息，如上圖所示。

此時，原來的leader副本恢復，成為了新的follower副本，準備向新的leader副本同步訊息，但是它發現自身的LEO比leader副本的LEO還要大。Kafka中有一個準則，follower副本的LEO是不能夠大於leader副本的，所以新的follower副本就需要截斷日誌至leader副本的LEO處。 

如上圖所示，新的follower副本需要刪除訊息4和訊息5，之後才能與新的leader副本進行同步。之後新的follower副本和新的leader副本組成了新的ISR集合，參考下圖。 

原本客戶端已經成功的寫入了訊息4和訊息5，而在發生日誌截斷之後就意味著這2條訊息就丟失了，並且新的follower副本和新的leader副本之間的訊息也不一致。也就是說如果unclean.leader.election.enable引數設定為true，就有可能發生資料丟失和資料不一致的情況，Kafka的可靠性就會降低；而如果unclean.leader.election.enable引數設定為false，Kafka的可用性就會降低。具體怎麼選擇需要讀者更具實際的業務邏輯進行權衡，可靠性優先還是可用性優先。從Kafka 0.11.0.0版本開始將此引數從true設定為false，可以看出Kafka的設計者偏向於可靠性，如果能夠容忍uncleanLeaderElection場景帶來的訊息丟失和不一致，可以將此引數設定為之前的老值——true。
--------------------- 
作者：朱小廝 
來源：CSDN 
原文：https://blog.csdn.net/u013256816/article/details/80790185 
版權宣告：本文為博主原創文章，轉載請附上博文連結！