kafka可靠性分析

分區可靠性保證

Kafka維護一個AR（All Partition）列表，由ISR（與Leader數據同步的Replica）和OSR（與Leader數據不一樣步的Replica）組成。剛開始全部的副本都在ISR中，在kafka工做的過程當中，由於各類問題（網絡、磁盤、內存）致使某些副本同步速度慢於replica.lag.time.max.ms指定的閾值，則它們被踢出ISR，移動到OSR中。 kafka默認配置下，ISR中的全部Replica數據從Leader中同步完成，生產者纔會認爲數據提交成功，所以ISR的數據不易過多，並且他們之間的網絡也應該暢通。OSR內的Replica是否同步了leader的數據不影響數據是否提交成功，它們會盡力不斷從Leader中同步數據（出現OSR須要及時運維人員，排查故障，讓其儘快回到ISR中，下降集羣宕機的風險)

截斷機制

.HW(HighWatermark)：數據被成功提交（ISR中的全部Replica同步完成），HW更新到該位置，HW以前的數據才能夠被消費者訪問，保證沒有同步完成的數據不會被消費者訪問到，這就是隔離性（兩個事務之間互不影響）。

在leader宕機後，只能從ISR列表中選取新的leader，不管ISR中哪一個副本被選爲新的leader都知道HW以前的數據，能夠保證在切換了leader後，消費者能夠繼續看到以前已經提交的數據

 

若是leader宕機，選出了新的leader，而新的leader並無徹底同步以前leader的全部數據，以後又接受了新的數據，此時舊的leader恢復，則會發現新的leader中的數據和本身持有的數據不一致，此時舊的leader會將本身的數據截斷到宕機以前的hw位置，並同步新leader的數據

生產可靠性保證

生產者向leader發送數據時，能夠選擇須要的可靠性級別 ，經過request.required.acks參數配置：

0 - 生產者不停向leader發送數據，而不須要leader反饋成功消息
        這種模式效率最高，可靠性最低
        可能在發送過程當中丟失數據
        可能在leader宕機時丟失數據
​
    1 - 生產者發送數據給leader，leader收到數據後要等到ISR列表中的全部副本都同步數據完成後，才向生產者發送成功消息，若是一直收不到成功消息，則認爲發送數據失敗會自動重發數據.
        這種模式下可靠性很高，可是當ISR列表中只剩下leader時，當leader宕機讓然有可能丟數據
        此時能夠配置min.insync.replicas指定要求觀察ISR中至少要有指定數量的副本，默認該值爲1，須要改成大於等於2的值
        這樣當生產者發送數據給leader可是發現ISR中只有leader本身時，會收到異常代表數據寫入失敗，此時沒法寫入數據，保證了數據絕對不丟
        雖然不丟可是可能會多數據，例如生產者發送數據給leader，leader同步數據給ISR中的follower，同步到一半leader宕機，此時選出新的leader，可能具備部分這次提交的數據，而生產者收到失敗消息重發數據，新的leader接受 數據則數據重複了

所以kafka只支持At Most Once和At Least Once，不支持Exactly Once（到業務中去重）

leader選舉

默認配置下，當leader宕機時會選擇ISR中的一個follower成爲新的leader，若是ISR中的全部副本都宕機，而又要求集羣可用，那麼有下面兩種選擇：

1.必須等待ISR列表中的副本活過來才選擇其成爲leader繼續工做，將unclean.leader.election.enable設置爲false

2.選擇任何一個活着的副本可能不在ISR中成爲leader繼續工做，將unclean.leader.election.enable設置爲true

第一種方法，可靠性有保證，可是可用性變低，只有最後掛了的leader活過來kafka集羣才能繼續工做

第二種方法，可用性高，可靠性沒有保證，任何一個副本活過來就能夠繼續工做，可是有可能存在數據不一致的狀況