問(wèn)題1：Kafka Topic ISR不全
Leader會(huì)跟蹤與其保持同步的Replica列表噪伊，該列表稱(chēng)為ISR（即in-sync Replica）亡脑。如果一個(gè)Follower宕機(jī)次哈，或者落后太多莹规，Leader將把它從ISR中移除请梢。這里所描述的“落后太多”指Follower復(fù)制的消息落后于Leader后的條數(shù)超過(guò)預(yù)定值（該值通過(guò)replica.lag.max.messages配置正歼，其默認(rèn)值是4000）或者Follower超過(guò)一定時(shí)間（該值通過(guò)replica.lag.time.max.ms來(lái)配置辐马，其默認(rèn)值是10000）未向Leader發(fā)送fetch請(qǐng)求。
解決方法
將下面幾個(gè)參數(shù)適當(dāng)增大：
replicas響應(yīng)leader的最長(zhǎng)等待時(shí)間局义，若是超過(guò)這個(gè)時(shí)間喜爷，就將replicas排除在管理之外
replica.lag.time.max.ms = 1000000ms （默認(rèn)10000ms）
如果relicas落后太多,將會(huì)認(rèn)為此partition relicas已經(jīng)失效。而一般情況下,因?yàn)榫W(wǎng)絡(luò)延遲等原因,總會(huì)導(dǎo)致replicas中消息同步滯后萄唇。如果消息嚴(yán)重滯后,leader將認(rèn)為此relicas網(wǎng)絡(luò)延遲較大或者消息吞吐能力有限檩帐。在broker數(shù)量較少,或者網(wǎng)絡(luò)不足的環(huán)境中,建議提高此值.
replica.lag.max.messages = 100000 （默認(rèn)4000）
leader中進(jìn)行復(fù)制的線(xiàn)程數(shù)，增大這個(gè)數(shù)值會(huì)增加relipca的IO
num.replica.fetchers = 2 (默認(rèn)1)
replicas每次獲取數(shù)據(jù)的最大字節(jié)數(shù)
replica.fetch.max.bytes = 10M （默認(rèn)10M）
問(wèn)題2：topic1和topic2分區(qū)都為20另萤，只分布在3個(gè)broker點(diǎn)上湃密，其余6個(gè)broker空閑
解決方法
增加topic1分區(qū)數(shù)為50，topic2分區(qū)數(shù)為100四敞，分區(qū)均勻分布在9個(gè)broker上泛源，觀(guān)察Spark Streaming程序并行度增大，處理效率提高忿危，延遲明顯變小达箍。
增加topic分區(qū)數(shù)命令，將topic t_topic1分區(qū)數(shù)增大到50個(gè)分區(qū)：
kafka-topics --zookeeper node01:2181 --alter --topic t_topic1 --partitions 50
問(wèn)題3：java.lang.AssertionError：assertion failed: Failed to get records for spark-executor-group t_topic1 after polling for 512
Spark Streaming程序報(bào)同一個(gè)stage的某些task獲取不到數(shù)據(jù)超時(shí)后失敗
解決方法
適當(dāng)增大spark.streaming.kafka.consumer.poll.ms=1000 (默認(rèn)512)
平臺(tái)業(yè)務(wù)運(yùn)行恢復(fù)正常铺厨。
參考
http://www.cnblogs.com/wangb0402/p/6221626.html
https://community.mapr.com/thread/18619-problems-with-spark-161-1607
http://kafka.apache.org/documentation/#configuration
