由kafka的lag延迟引发的partitions数和consumers数的调整

问题描述：
有一个topic为nams_flume_imp，有两个消费者组**-imp-adv-log 和 ****_logstash_imp来消费该topic，每个消费者组目前只有一个消费者，每个消费者只有一个线程。
Kafka有6个partition，也就是说每个消费者组只有一个消费者线程来消费6个partition的log数据。
通过查看kafkamanage，发现****_logstash_imp组的消费能力比较可观，没有消费延迟，如下图：

而**-imp-adv-log的消费能力差一些。0,1,2三个partition存在较大的lag(延迟)，如下：

通过观察 Consumer Instance Owner，发现两个消费者组都只有一个消费者实例。因此推测是由于消费者实例太少导致的消费能力不足，此我们要增加消费者实例。参考http://www.cnblogs.com/huxi2b/p/4757098.html (很详细)
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-kafka.html#plugins-inputs-kafka-consumer_threads
两者的介绍，决定把消费者实例提升为6个，这样可以保证对同一个consumer group而言，每个partition都有一个consumer来消费他。修改logstash的input的consumer_threads配置。

到这里又涉及到了一个问题，就是怎么将消费者实例提升为6个？我当时想了两种方案。其一，单起一个logstash进程，在logstash中配置consumer_threads数为6，即一个logstash进程中有包含6个consumer线程；其二，三台物理机每台都起一个logstash进程，然后consumer_threads设为2。第一种因为6个consumer都在一台机器上，相对来讲会比较耗费单台计算机的资源（cpu，内存，IO，网络），第二种是一种均衡负载的做法，比较合理。因此我采用了后一种做法。

修改之后，发现lag数在慢慢减少，经过一段时间，lag数已经基本已经为0，说明消费能力上来了，基本没有消费延迟。如下：

我们观察Consumer Instance Owner，发现有有三个不同的前缀，“7d61”，”9908”，“8013”，这表示的是起的三个logstash进程，每个进程包含两个consumer，也就与我们在logstash中设置的consumer_threads=>2 对应起来了。

关于官网说的consumer instance即消费者实例的理解，见下一篇博客的分析实践
http://blog.csdn.net/nyyjs/article/details/72771905