Kafka版本0.10.0
spark版本 2.1
Spark streaming在同一个application中多个kafka source当使用一个group id的时候订阅不同topic会存在消息消费堆积，并且控制页面streaming时间会存在严重延时。
在spark根据存在的输出流依次生成job的时候，将会依次串行调用各个kafka source的compute()方法从kafka中拉取信息，在准备拉取消息之前，如果当前消费者没有加入到kafka中，将会发出join请求到kafka中尝试加入，尝试加入请求操作将会导致该kafka对这个消费者组进行rebanance操作（同步），可能会导致长时间的阻塞。
当多个流使用同一个groupid订阅不同topic之后，一段时间之后，其中一个消费者metadata中的消费者组总订阅情况将会更新，导致其在下一次拉取数据的时候会重新发起join请求导致rebalance阻塞，而其他的消费者的心跳消息接收由于超时而也从消费者组中被踢出而准备重新进入。
以上一个重要的地方在于，在job生成阶段，source是串行从kafka拉取消息的，join请求同一时间只会有一个消费者发出，此处的阻塞将会直接导致其他消费者的心跳超时而准备重新加入，当前一个消费者终于完成join操作并拉取到消息，下一份source才会进入拉取阶段，而由于前一个消费者的阻塞，其已经不在当前消费者组中，将会重新发起join请求加入，此处的阻塞导致前一个消费者的超时而重新被踢出，如此恶性循环，每个消费者尝试拉取消息的时候都会发生rebalance阻塞并引起整体的消费堆积，由于阻塞之处在拉取消息之前，在spark页面将无法看到具体的deplay信息，整体消息获取阻塞导致内部时间累加器时间计算滞后，spark页面上展示的时间批次滞后。
