#############################Consumer #############################
# Consumer端核心的配置是group.id、zookeeper.connect
# 决定该Consumer归属的唯一组ID，By setting the same group id multiple processes indicate that they are all part of the same consumer group.
group.id
# 消费者的ID，若是没有设置的话，会自增
consumer.id
# 一个用于跟踪调查的ID ，最好同group.id相同
client.id = <group_id>
?
# 对于zookeeper集群的指定，必须和broker使用同样的zk配置
zookeeper.connect=debugo01:2182,debugo02:2182,debugo03:2182
# zookeeper的心跳超时时间，查过这个时间就认为是无效的消费者
zookeeper.session.timeout.ms = 6000
# zookeeper的等待连接时间
zookeeper.connection.timeout.ms = 6000
# zookeeper的follower同leader的同步时间
zookeeper.sync.time.ms = 2000
# 当zookeeper中没有初始的offset时，或者超出offset上限时的处理方式 。
# smallest ：重置为最小值?
# largest:重置为最大值?
# anything else：抛出异常给consumer
auto.offset.reset = largest
?
# socket的超时时间，实际的超时时间为max.fetch.wait + socket.timeout.ms.
socket.timeout.ms= 30 * 1000
# socket的接收缓存空间大小
socket.receive.buffer.bytes=64 * 1024
#从每个分区fetch的消息大小限制
fetch.message.max.bytes = 1024 * 1024
?
# true时，Consumer会在消费消息后将offset同步到zookeeper，这样当Consumer失败后，新的consumer就能从zookeeper获取最新的offset
auto.commit.enable = true
# 自动提交的时间间隔
auto.commit.interval.ms = 60 * 1000
?
# 用于消费的最大数量的消息块缓冲大小，每个块可以等同于fetch.message.max.bytes中数值
queued.max.message.chunks = 10
?
# 当有新的consumer加入到group时,将尝试reblance,将partitions的消费端迁移到新的consumer中, 该设置是尝试的次数
rebalance.max.retries = 4
# 每次reblance的时间间隔
rebalance.backoff.ms = 2000
# 每次重新选举leader的时间
refresh.leader.backoff.ms
?
# server发送到消费端的最小数据，若是不满足这个数值则会等待直到满足指定大小。默认为1表示立即接收。
fetch.min.bytes = 1
# 若是不满足fetch.min.bytes时，等待消费端请求的最长等待时间
fetch.wait.max.ms = 100
# 如果指定时间内没有新消息可用于消费，就抛出异常，默认-1表示不受限
consumer.timeout.ms = -1
?
?
?
------------------------------------Kafka配置参数--Consumer详解-----------------------------
?
?
group.id 默认值：无
唯一的指明了consumer的group的名字，group名一样的进程属于同一个consumer group。
?
zookeeper.connect 默认值：无
指定了ZooKeeper的connect string，以hostname:port的形式，hostname和port就是ZooKeeper集群各个节点的hostname和port。 ZooKeeper集群中的某个节点可能会挂掉，所以可以指定多个节点的connect string。如下所式：
hostname1:port1,hostname2:port2,hostname3:port3.
?
ZooKeeper也可以允许你指定一个"chroot"的路径，可以让Kafka集群将需要存储在ZooKeeper的数据存储到指定的路径下这可以让多个Kafka集群或其他应用程序公用同一个ZooKeeper集群。可以使用如下的connect string：
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path
?
consumer.id 默认值：null
如果没有设置的话则自动生成。
?
socket.timeout.ms 默认值：30 * 1000
socket请求的超时时间。实际的超时时间为max.fetch.wait + socket.timeout.ms。
?
socket.receive.buffer.bytes 默认值：64 * 1024
socket的receiver buffer的字节大小。
?
fetch.message.max.bytes 默认值：1024 * 1024
每一个获取某个topic的某个partition的请求，得到最大的字节数，每一个partition的要被读取的数据会加载入内存，所以这可以帮助控制consumer使用的内存。这个值的设置不能小于在server端设置的最大消息的字节数，否则producer可能会发送大于consumer可以获取的字节数限制的消息。
?
auto.commit.enable 默认值：true
如果设为true，consumer会定时向ZooKeeper发送已经获取到的消息的offset。当consumer进程挂掉时，已经提交的offset可以继续使用，让新的consumer继续工作。
?
auto.commit.interval.ms 默认值：60 * 1000
consumer向ZooKeeper发送offset的时间间隔。
?
queued.max.message.chunks 默认值：10
缓存用来消费的消息的chunk的最大数量，每一个chunk最大可以达到fetch.message.max.bytes。
?
rebalance.max.retries 默认值：4
当一个新的consumer加入一个consumer group时，会有一个rebalance的操作，导致每一个consumer和partition的关系重新分配。如果这个重分配失败的话，会进行重试，此配置就代表最大的重试次数。
?
fetch.min.bytes 默认值：1
一个fetch请求最少要返回多少字节的数据，如果数据量比这个配置少，则会等待，知道有足够的数据为止。
?
fetch.wait.max.ms 默认值：100
在server回应fetch请求前，如果消息不足，就是说小于fetch.min.bytes时，server最多阻塞的时间。如果超时，消息将立即发送给consumer.。
?
rebalance.backoff.ms 默认值：2000
在rebalance重试时的backoff时间。
?
refresh.leader.backoff.ms 默认值：200
在consumer发现失去某个partition的leader后，在leader选出来前的等待的backoff时间。
?
auto.offset.reset 默认值：largest
在Consumer在ZooKeeper中发现没有初始的offset时或者发现offset不在范围呢，该怎么做：
* smallest : 自动把offset设为最小的offset。
* largest : 自动把offset设为最大的offset。
* anything else: 抛出异常。
?
consumer.timeout.ms 默认值：-1
如果在指定的时间间隔后，没有发现可用的消息可消费，则抛出一个timeout异常。
?
client.id 默认值： group id value
每一个请求中用户自定义的client id，可帮助追踪调用情况。
?
zookeeper.session.timeout.ms 默认值：6000
ZooKeeper的session的超时时间，如果在这段时间内没有收到ZK的心跳，则会被认为该Kafka server挂掉了。如果把这个值设置得过低可能被误认为挂掉，如果设置得过高，如果真的挂了，则需要很长时间才能被server得知。
?
zookeeper.connection.timeout.ms 默认值：6000
client连接到ZK server的超时时间。
?
zookeeper.sync.time.ms 默认值：2000
一个ZK follower能落后leader多久。
原文：http://gaojingsong.iteye.com/blog/2304761