kafka叢集基於永續性指標進行效能調優實踐-kafka 商業環境實戰
摘要：
本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
1 蹦出...
本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
1 蹦出來一個永續性
- 永續性定義了kafka叢集中訊息不容易丟失的程度，永續性越高表明Kafka越不會丟失訊息。
- 永續性通常是通過冗餘來實現，而kafka實現冗餘的手段就是備份機制，該備份機制保證了Kafka的每一個訊息都會被儲存到多臺Broker上。
2 實際可行性調優
- 分割槽數和副本因子由broker端引數num.partitions和default.replication.factor指定，這兩個引數預設值都是1。
- 禁止kafka自動建立topic，可以引數設定auto.create.topics.enable=false。
- 新版本已經把consumer端位移資訊的儲存從Zookeeper轉移到了內部的topic __consumer_offsets中，注意這個也同樣會受到default.replication.factor引數影響。0.11.0.0要求__consumer_offsets建立時必須滿足default.replication.factor，若Broker小於default.replication.factor會直接報錯。
- 若要達到最高的永續性，必須設定acks=all(或者acks=-1)，即強制leader副本等待的ISR中所有副本都響應了某條訊息後傳送response給producer。
- producer傳送失敗後，會進行重試機制，比如網路臨時抖動。
- 當Producer重試後，待發送的訊息可能已經成功，假如資料已經落盤寫入日誌，在傳送response給Producer時出現了故障，重試時就會再次傳送同一條訊息，也就出現了重複的訊息。自從0.11.0.0版本開始，kafka提供了冪等性Producer，實現了精確一次的處理語義。冪等性Producer保證同一條訊息只會被broker寫入一次。啟動這樣設定：enable.idempotence=true。
- 訊息亂序處理機制，producer依次傳送訊息m1和m2，若m1寫入失敗但m2寫入成功，一旦重試m1，那麼m1就位於m2的後面了。如果對訊息的順序要求比較嚴格的話，max.in.flight.requests.per.connection=1來規避這個問題。該引數目的保證單個producer連線上在任意某個時刻只處理一個請求。
- 當某個Broker出現出現崩潰時，controller會自動檢測出宕機的broker併為該Broker上的所有分割槽重新選舉leader，選擇的範圍是從ISR副本中挑選。若ISR副本所在的broker全部宕機，Kafka就會從非ISR副本中選舉leader。這種情況下就會造成不同步和訊息丟失。是否允許Unclean選舉，藉助unclean.leader.election.enable引數控制，0.11.0.0版本預設是false。
- min.insync.replicas，若成功寫入訊息時則必須等待響應完成的最少ISR副本，該引數是在acks=all時才會生效。
- 本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
- 自0.10.0.0版本開始，kafka仿照Hadoop為broker引入機架屬性資訊（rack）,該引數由broker.rack設定。Kafka叢集在後臺會收集所有的機架資訊仔仔建立分割槽時將分割槽分散到不同的機架上。
- 日誌持久化：兩個重要引數log.flush.interval.ms和log.flush.interval.message。前者指定了Kafka多長時間執行一次訊息“落盤”，後者是寫入多少訊息後執行一次訊息“落盤”。預設情況下，log.flush.interval.ms是空而將log.flush.interval.message設定為Long.MAX_VALUE，這個表示Kafka實際上不會自動執行訊息的“沖刷”操作，事實上這也是kafka的設計初衷。即把訊息同步到磁碟的工作交由作業系統來完成，由作業系統控制頁快取資料到物理檔案的同步。但是若使用者希望每一條訊息都沖刷一次，及時持久化，可以設定log.flush.interval.message=1。
- 提交位移的持久化，實際應用中設定auto.commit.enable=false，同時使用者需要使用commitSync方法來提交位移，而非commitAsync方法。
3 引數清單
broker端
- 設定unclean.leader.election.enable-false(0.11.0.0之前版本)
- 設定auto.create.topics.enable=false
- 設定replication.factor=3，min.insync.replicas=replication.factor-1
- 設定default.replication.factor=3
- 設定broker.rack屬性分散分割槽資料到不同的機架。
- 設定log.flush.interval.ms和log.flush.interval.message為一個較小的值。
- 本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。 producer端
- 設定acks=all
- 設定retries為一個較大的值，比如10-30。
- 設定max.in.flight.request.per.connection=1
- 設定enable.idempotence=true
consumer端
- 設定auto.commit.enable=false
- 訊息消費成功後，呼叫commitSync提交位移。
4 總結
enable.idempotence=true 和max.in.flight.request.per.connection=1以及broker.rack屬性比較新穎，值得一試。
秦凱新 於深圳 201812042131
本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。