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