Kafka Topic ISR不全，個別Spark task處理時間長

現象

Spark streaming讀kafka數據作業務處理時，同一個stage的task,有個別task的運行時間比多數task時間都長，形成業務延遲增大。

查看業務對應的topic發現當topic isr不足時，會出現個別task運行時間過長的現象.

緣由

和大部分分佈式系統同樣，Kafka處理失敗須要明肯定義一個Broker是否「活着」。對於Kafka而言，Kafka存活包含兩個條件，一是它必須維護與ZooKeeper的session（這個經過ZooKeeper的Heartbeat機制來實現）。二是Follower必須可以及時將Leader的消息複製過來，不能「落後太多」。

Leader會跟蹤與其保持同步的Replica列表，該列表稱爲ISR（即in-sync Replica）。若是一個Follower宕機，或者落後太多，Leader將把它從ISR中移除。這裏所描述的「落後太多」指Follower複製的消息落後於Leader後的條數超過預約值（該值經過replica.lag.max.messages配置，其默認值是4000）或者Follower超過必定時間（該值經過replica.lag.time.max.ms來配置，其默認值是10000）未向Leader發送fetch請求。

解決方法

將下面幾個參數適當增大：

replicas響應leader的最長等待時間，如果超過這個時間，就將replicas排除在管理以外

replica.lag.time.max.ms = 10000

若是relicas落後太多,將會認爲此partition relicas已經失效。而通常狀況下,由於網絡延遲等緣由,總會致使replicas中消息同步滯後。若是消息嚴重滯後,leader將認爲此relicas網絡延遲較大或者消息吞吐能力有限。在broker數量較少,或者網絡不足的環境中,建議提升此值.

replica.lag.max.messages = 4000

leader中進行復制的線程數，增大這個數值會增長relipca的IO

num.replica.fetchers = 1

replicas每次獲取數據的最大字節數

replica.fetch.max.bytes = 1024 * 1024