kafka中文文档old comsumer配置参数

         该文档对应的是 kafka安装目录/config/consumer.properties文件的内容，此份配置是老版本的kafka。由于原英文版的文档从句太多太难理解，我花了四天时间翻译了一份中文文档，希望给大家带来帮助，有问题请留言。可能网页显示不全，请下载附件PDF。

 

名称	默认	描述
group.id		标识该消费者所属的消费者进程组的唯一性字符串。多个进程通过设置同一个组标识，表示它们都是同一个消费组的一部分。
zookeeper.connect		指定ZooKeeper的连接字符串，以主机名:端口作为格式，主机名和端口是ZooKeeper服务器的主机名和端口。为了允许当ZooKeeper机器关闭时连接到其它的ZooKeeper节点你可以指定多个主机，格式为hostname1:port1,hostname2:port2,hostname3:port3 。服务器也可以有一个ZooKeeper可改变的路径作为ZooKeeper连接字符串的的一部份，将数据放在全局的ZooKeeper命名空间的一些路径中。如果这样消费者应该在它的连接路径中使用相同的可改变的路径。例如给出/chroot/path的一个可变路径，你可以给出这样的连接字符串   hostname1:port1,hostname2:port2,hostname3:port3/chroot/path 。
consumer.id	null	如果没有被设置，会自动创建。
socket.timeout.ms	30 * 1000	网络请求套接字超时。实际的超时设置为max.fetch.wait + socket.timeout.ms。
socket.receive.buffer.bytes	64 * 1024	网络请求的套接字接收缓冲。
fetch.message.max.bytes	1024 * 1024	在每个读取请求中每个主题分区尝试读取的消息字节数量。为每个分区把字节读到内存中，所以这个帮助控制消费者使用的内存。获取请求大小必须至少与服务器允许的最大消息大小一样大，否则生产者就可以发送比用户能获取的更大的消息。
num.consumer.fetchers	1	用来读取数据的读取器线程数量。
auto.commit.enable	TRUE	如果设为true，周期性的提交被消费者读取的消息偏移量到ZooKeeper。当进程失败时这个已提交的偏移将被使用，作为新的消费者开始的位置。
auto.commit.interval.ms	60 * 1000	消费者偏移被提交到zookeeper的频率，以毫秒为单位。
queued.max.message.chunks	2	消费的缓冲消息块的数量。每个块可以达到fetch.message.max.bytes
rebalance.max.retries	4	当一个新消费者加入一个消费者组，消费者集合尝试重平衡负载来分配分区给每个消费者。当这个分配正在发生时如果消费者集合改变了，重平衡会失败并重试。此设置控制在放弃之前最多尝试次数。
fetch.min.bytes	1	服务器为每个读取请求返回的数据的最小数量。如果没有足够的数据可用，在响应之前请求会等待有足够的数据。
fetch.wait.max.ms	100	如果没有足够的数据立即满足fetch.min.bytes的值，时间服务器在响应读取请求之前服务器阻塞的最大时间。
rebalance.backoff.ms	2000	在重新平衡期间重试之间的延迟时间。如果没有显式设置，用zookeeper.sync.time.ms的值。
refresh.leader.backoff.ms	200	在确定一个刚刚失去领导者的分区的领导者之前，需要等待的时间。
auto.offset.reset	largest	当在ZooKeeper中没有初始的偏移或偏移已超出范围：* smallest : 自动重置偏移到最小偏移 * largest : 自动重置偏移到最大偏移 * anything else: 抛出一个异常给消费者
consumer.timeout.ms	-1	抛出一个超时异常给消费者，如果在指定的间隔内没有没有可用的消息。
exclude.internal.topics	TRUE	来自内部主题（例如偏移）的消息是否暴露给消费者。
client.id	group id value	用户标识是用户指定的字符，在每次请求发送时用于追踪调用。它应该可以逻辑上区分应用请求。
zookeeper.session.timeout.ms	6000	ZooKeeper 会话超时时间。如果在这个周期内消费者到ZooKeeper之间的心跳失败，那么它被认为是死亡的并且会发生重新平衡。
zookeeper.connection.timeout.ms	6000	客户端建立到zookeeper之间连接等待的最长时间。
zookeeper.sync.time.ms	2000	Zookeeper的跟随者在Zookeeper领导者之后的距离。
offsets.storage	zookeeper	选择偏移所保存的地方，(zookeeper 或  kafka)。
offsets.channel.backoff.ms	1000	重新连接偏移渠道或试失败的偏移提取/提交请求的回退周期。
offsets.channel.socket.timeout.ms	10000	为偏移读/提交请求读取响应的超时时间。这个超时也用于用来偏移管理请求的ConsumerMetadata请求。
offsets.commit.max.retries	5	重试失败的偏移提交一直达到这个属性值的大小。这个重试计数只适用于在关闭期间的偏移提交。它不适用于自动提交线程的提交。它也不适用于在提交偏移之前查询偏移协调器的尝试。例如，如果一个消费者元数据请求因任何原因而失败，它将重试，重试不计入该限制。
dual.commit.enabled	TRUE	如果你使用"kafka" 作为offsets.storage的值，你可以提交两次偏移到ZooKeeper（除了kafka外）。这是在从zookeeper-based 偏移存储升级到 to kafka-based 偏移存储期间所必须的。对于任何给定的消费者组，在那个组里的所有实例升级到提交偏移到broker（取代直接到ZooKeeper）的新版本之后关闭它，这样才是安全的。
partition.assignment.strategy	range	在"range" 或 “roundrobin”策略之间选择用来分配分区给消费者流。循环赛分区分配器展示了所有的可用的分区和所有可用的消费者线程。然后从分区到用户进行循环赛分配。如果所有用户的订阅都是可识别的，分区将会统一分发。（分区所有者计数值将会是所有消费者线程中的一个具体的变量）。循环赛分配只有在以下条件下允许：（a）在一个消费者实例中每个主题都有相同的流数字。(b)订阅主题的集合对于组里每个消费者来说是可识别的。范围分区是基于每个主题。对于每个主题，我们按数字顺序展示了可用的分区并且按字典顺序勾画了消费者线程。然后，我们根据消费者流（线程）的总数来划分分区的数量，以确定分配给每个消费者的分区数。如果它不均匀地分配，那么头几个消费者将有一个额外的分区。