KAFKA 1.0 文档（六）：消费者配置
- 新的消费者配置
- 老消费者配置
新的消费者配置
| Name | Description | 类型 | 默认值 | 重要性 |
|---|---|---|---|---|
| bootstrap.servers | 用于建立与kafka集群连接的host/port组。数据将会在所有servers上均衡加载，不管哪些server是指定用于bootstrapping。这个列表仅仅影响初始化的hosts（用于发现全部的servers 这个列表格式： host1:port1,host2:port2,… 因为这些server仅仅是用于初始化的连接，以发现集群所有成员关系（可能会动态的变化），这个列表不需要包含所有的servers（你可能想要不止一个server，尽管这样，可能某个server宕机了）。如果没有server在这个列表出现，则发送数据会一直失败，直到列表可用。 |
list | 高 | |
| key.deserializer | 实现了Deserializer接口的反序列化类 | class | 高 | |
| value.deserializer | 值的实现了Deserializer接口的反序列化类， | class | 高 | |
| fetch.min.bytes | 每次获取数据请求时，server应该返回的最小字节数。如果没有足够的数据返回，请求会等待，直到足够的数据才会返回。默认值设置成1意味着fetch请求会尽快得到应答，在得到一个单字节的数据或者fetch请求在等待数据返回的时候超时的时候。如果此设置的值大于1，将导致server等待汇聚更多的数据，花费一些额外的延迟时间可提高server的吞吐量。 | int | 1 | 高 |
| group.id | 用来唯一标识consumer进程所在组的字符串，如果设置同样的group id，表示这些进程都是属于同一个consumer group。如果消费者通过使用订阅（topic）或者基于kafka的offset管理策略来使用组管理功能，则这个选项是必须配置的。 | String | “” | 高 |
| heartbeat.interval.ms | consumer 向 coordinator发送心跳间隔时间，该值必须小于session.timeout.ms，但通常应设置不超过该值的1/3。它可以调整得更低，以控制为正常重新平衡预期时间。 | int | 3000 | 高 |
| max.partition.fetch.bytes | 每个分区partiton返回的最大的数据量。请求的最大内存使用值为consumer的分区个数*max.partition.fetch.bytes。这个值的大小必须至少为服务器允许的最大消息大小，否则可能producer发送的消息大小超过这个consumer能获取的最大值，如果出现这种情况，消费者会在从某个分区中获取一个超大的消息时卡住。 | int | 1048576 | 高 |
| session.timeout.ms | 当使用组管理工具时的检测故障超时时间，如果在这个时间内，消费者没有向协调者发送心跳，则标识该消费者已经死亡。 | int | 30000 | 高 |
| auto.offset.reset | 在kafka中没有初始的offset或者当前的offset不存在（比如。因为数据已经被删除），将返回的offset值： earliest：自动重置offset到一个最早的偏移量 latest：自动重置offset到一个最新的偏移量 none：如果在消费者的组中没有发现之前的offset就向消费者抛出异常 anything else：向消费者抛出异常 |
string | latest | 中 |
| ssl.key.password | 秘钥存储文件中的秘钥密码。 | password | null | 高 |
| ssl.keystore.location | 秘钥文件的存储位置。这个可选的配置可用于为客户端提供双向认证。 | string | null | 高 |
| ssl.keystore.password | 密钥存储文件的存储密码，和ssl.keystore.location配合使用 | password | null | 高 |
| ssl.truststore.location | 信任文件的存储位置 | string | null | 高 |
| ssl.truststore.password | 信任文件的密码 | password | null | 高 |
| connections.max.idle.ms | 连接最大空闲时间，如果超过这个时间没有消息被获取，则关闭连接 | long | 540000 | 中 |
| enable.auto.commit | 如果为true，消费者会定期在后台提交offset偏移量。 | boolean | true | 中 |
| exclude.internal.topics | 内部topic（如offsets）的记录是否应该暴露给消费者。 如果设置为true，则从内部主题接收数据的唯一方法是订阅它。 | boolean | true | 中 |
| fetch.max.bytes | 服务器获取数据请求而返回的最大数据量。 记录由消费者批量提取，如果第一个非空分区中的第一个 record batch大于此值，则 record batch仍将被返回以确保消费者可以进行。 因此，这不是一个绝对的最大值。 broker接受的最大 record batch大小是通过message.max.bytes（broker config）或max.message.bytes（topic config）定义的。 请注意，消费者并行执行多个提取。 | int | 52428800 | 中 |
| isolation.level | 控制如何阅读事务处理的消息。 如果设置为read_committed，则consumer.poll（）将仅返回已提交的事务性消息。 如果设置为read_uncommitted（默认），consumer.poll（）将返回所有的消息，甚至是已经中止的事务消息。 非事务消息将在任一模式下无条件返回。 消息将始终以偏移顺序返回。 因此，在read_committed模式下，consumer.poll（）将只返回最后一个稳定偏移（LSO）的消息，这比第一个打开事务的偏移量小。 特别是在进行中的事务的消息之后出现的任何消息将被扣留，直到相关的事务完成。 因此，当有坏掉的事务时，read_committed的使用者将无法读取最新数据。而且，在read_committed时，seekToEnd方法将返回LSO |
string | read_uncommitted | 中 |
| max.poll.interval.ms | 在使用消费者组管理时，再次调用poll()方法的最大延迟。 消费者在获取更多记录之前可以空闲的时间的上界。 如果在此超时到期之前未调用poll（），则认为消费者失败，并且组将重新平衡以将分区重新分配给其他成员。 | int | 300000 | 中 |
| max.poll.records | 在一次调用poll()中返回的最大记录数。 | int | 500 | 中 |
| partition.assignment.strategy | 分区分配策略的类，当使用组管理时，客户端将用此策略为消费者实例分配分区的所有权 | list | [org.apache. kafka.clients. consumer. RangeAssignor] |
中 |
| receive.buffer.bytes | TCP 接受缓存大小，当读取数据时使用 | int | 32768 | 中 |
| request.timeout.ms | 客户端发送请求等待响应的时间。如果超时则表示此次请求失败，必要时将重新发送请求。 | 中 | ||
| sasl.kerberos.service.name | 中 | |||
| security.protocol | 用于和broker通信的协议。符合的值为： PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL | string | PLAINTEXT | 中 |
| send.buffer.bytes | TCP发送缓存大小，当发送数据时使用 | int | 131072 | 中 |
| ssl.enabled.protocols | 对SSL连接启用的协议列表 | list | [TLSv1.2, TLSv1.1, TLSv1] |
中 |
| ssl.keystore.type | 秘钥存储文件的格式。可选 | string | JKS | 中 |
| ssl.protocol | 用于生成SSLContext的SLL协议，默认的TLS使用于大多数情况。在最新的JVM中允许的值有TLS, TLSv1.1 和TLSv1.2。或许在老的JVM中也支持SSL, SSLv2 和SSLv3，但是因为有已知的安全漏洞不鼓励使用。 | string | TLS | 中 |
| ssl.provider | 用于SSL连接的安全提供商的名称。默认是JVM的默认安全提供商。 | string | null | 中 |
| ssl.truststore.type | truststore文件的格式。 | string | JKS | 中 |
| auto.commit.interval.ms | 如果enable.auto.commit设置成true，消费者向kafka自动提交offsets的频率。 | long | 5000 | 低 |
| client.id | 一个每次请求都会传递给server的字符串id。 | string | “” | 低 |
| fetch.max.wait.ms | 如果没有足够的数据能够满足fetch.min.bytes，则此项配置是指在应答fetch请求之前，server会阻塞的最大时间。 | int | 500 | 低 |
| interceptor.classes | 用作拦截器的类的列表。 实现ConsumerInterceptor接口允许你拦截消费者接收到的记录。 默认情况下，没有拦截器。 | list | null | |
| metadata.max.age.ms | 以毫秒为单位的时间，强制metadata刷新时间 | long | 300000 | 低 |
| metric.reporters | 用户衡量指标的一组类的集合，实现MetricReporter接口，允许以插件方式加入类中，并将通知新的指标创建，总会包含一个JmxReporter用于注册JMX的统计 | list | [] | 低 |
| metrics.num.samples | 用于维护metrics的样本数 | int | 2 | 低 |
| metrics.sample.window.ms | metrics系统维护可配置的样本数量，在一个可修正的window size。这项配置配置了窗口时间，例如。我们可能在30s的期间维护两个样本。当一个窗口推出后，我们会擦除并重写最老的窗口 | long | 30000 | 低 |
| reconnect.backoff.max.ms | long | 1000 | 低 | |
| reconnect.backoff.ms | 连接失败时，重新连接时的等待时间。 | long | 50 | 低 |
| retry.backoff.ms | 当向指定的topic分区发送fetch请求失败时 ，消费者会试图重新发送请求 ， 这个配置就是重新发送请求的间隔时间。避免了不停快速的重复fetching-and–failing 。 | long | 100 | 低 |
| sasl.kerberos.kinit.cmd | Kerberos kinit 命令的路径 | string | /usr/bin/kinit | 低 |
| sasl.kerberos.min.time. before.relogin |
在尝试刷新之前的登陆线程休眠时间 | long | 60000 | 低 |
| ssl.endpoint.identification. algorithm |
用server证书验证server主机名的终端识别算法 | string | null | 低 |
| ssl.keymanager.algorithm | 为SLL连接使用秘钥管理工厂的算法，默认值是配置的JVM的秘钥管理工厂算法。 | string | SunX509 | 低 |
| ssl.trustmanager.algorithm | 为SLL连接使用信任管理工厂的算法，默认值是配置的JVM的信任管理工厂算法。 | string | PKIX | 低 |
老消费者配置
基本的老消费者配置如下：
- group.id
- zookeeper.connect
| Name | Description | 默认值 |
|---|---|---|
| group.id | 用来唯一标识consumer进程所在组的字符串，如果设置同样的group id，表示这些进程都是属于同一个consumer group | |
| zookeeper.connect | 指定zookeeper的连接的字符串，格式是hostname：port，此处host和port都是zookeeper server的host和port，为避免某个zookeeper 机器宕机之后失联，你可以指定多个hostname：port，使用逗号作为分隔： hostname1：port1，hostname2：port2，hostname3：port3 可以在zookeeper连接字符串中加入zookeeper的chroot路径，此路径用于存放他自己的数据，方式： hostname1：port1，hostname2：port2，hostname3：port3/chroot/path |
|
| consumer.id | 不需要设置，一般自动产生 | null |
| socket.timeout.ms | 网络请求的超时限制。真实的超时限制是 max.fetch.wait + socket.timeout.ms | 30 * 1000 |
| socket.receive.buffer.bytes | socket用于接收网络请求的缓存大小 | 64 * 1024 |
| fetch.message.max.bytes | 每次fetch请求中，针对每个topic-分区每次fetch消息的最大字节数。这些字节将会被读入partition的内存中，因此，此设置将会控制consumer所使用的内存大小。这个fetch请求尺寸必须至少和server允许的最大消息尺寸相等，否则，producer可能发送的消息大小大于consumer所能消耗的大小。 | 1024 * 1024 |
| num.consumer.fetchers | 于fetch数据的线程数 | 1 |
| auto.commit.enable | 如果为true，consumer所读取的消息的偏移量将会自动的同步到zookeeper。已提交的偏移量将在消费进程挂掉时，新的consumer线程使用这个偏移量读取数据 | true |
| auto.commit.interval.ms | consumer向zookeeper提交offset的频率，单位是毫秒 | 60 * 1000 |
| queued.max.message.chunks | 用于缓存最大消息块，以供消费。每个块的大小最多值能和fetch.message.max.bytes相同 | 2 |
| rebalance.max.retries | 当新的consumer加入到consumer group时，一组consumers试图重新平衡分配每个consumer的分区数目。如果当分配正在执行时consumers集合改变了，重新平衡将会失败并且重试，这个配置就是控制最大的重试次数 | 4 |
| fetch.min.bytes | 每次获取数据请求时，server应该返回的最小字节数。如果没有足够的数据返回，请求会等待，直到足够的数据才会返回。 | 1 |
| fetch.wait.max.ms | 如果没有足够的数据能够满足fetch.min.bytes，则此项配置是指在应答fetch请求之前，server会阻塞的最大时间。 | 100 |
| rebalance.backoff.ms | 在重试reblance之前间隔时间 | 2000 |
| refresh.leader.backoff.ms | 在试图确定某个刚失去leader的分区的新的leader之前，需要等待的间隔时间 | 200 |
| auto.offset.reset | zookeeper中没有当前customer提交的offset时，将返回的offset值： smallest：自动复位offset为smallest的offset largest：自动复位offset为largest的offset anything else：向consumer抛出异常largest |
|
| consumer.timeout.ms | 如果在等待指定的时间间隔后没有消息可用，则抛出超时异常 | -1 |
| exclude.internal.topics | 是否将topics的内部消息（比如offsets）暴露给consumer | true |
| client.id | 用户指定一个字符串格式的client id在每次请求中都会作为参数提交，可用户跟踪请求，它应该能够识别出发出请求的应用。 | group id value |
| zookeeper.session.timeout.ms | zookeeper 会话的超时限制。如果consumer在这段时间内没有向zookeeper发送心跳信息，则它会被认为挂掉了，并且将会触发reblance | 6000 |
| zookeeper.connection.timeout.ms | 客户端在建立zookeeper连接中的最大等待时间 | 6000 |
| zookeeper.sync.time.ms | ZK 从阶段可以落后主节点的最大时间 | 2000 |
| offsets.storage | 选择在哪里保存偏移量（zookeeper 或者kafka) | zookeeper |
| offsets.channel.backoff.ms | 重新连接offsets channel或者是重试失败的的fetch/commit offset请求的间隔时间 |
1000 |
| offsets.channel.socket.timeout.ms | 当读取offset的fetch/commit请求回应的socket 超时限制。此超时限制也适用于查询offset管理的consumerMetadata请求 | 10000 |
| offsets.commit.max.retries | offset commit失败重试的次数。这个重试次数仅在停机期间提交offset commit时计数。它不适用从自动提交线程发起的commit。也不适用于试图在提交offset之前查询offset coordinator 。例如，由于某种原因，消费者的元数据请求失败，它将会重试，但是不计入此重试次数。 | 5 |
| dual.commit.enabled | 如果使用“kafka”作为offsets的存储，你可以双重提交offset到zookeeper(还有一次是提交到kafka）。这就需要从zookeeper-based中的offset存储到kafka-based的offset存储迁移时。对任意指定的consumer group来说，比较安全的建议是当完成迁移之后就关闭这个选项 | true |
| partition.assignment.strategy | 选择作为分配partitions给consumer 数据流的策略，可选项为“range”和“roundrobin”。 roundrobin策略列出所有可用的分区和所有可用的消费者线程，然后把分区往消费者线程轮询分配，如果所有订阅的消费者实例是相同的，则分区将被均匀地分布（比如分区个数刚好等于消费者线程数）。循环分配策略只有在以下条件满足时才可以： （1）每个topic在每个consumer实例上都有同样数量的数据流。 （2）订阅的topic的集合对于consumer group中每个consumer实例来说都是确定的。 range其实就是按照阶段平均分配。举个例子就明白了，假设你有10个分区，P0 ~ P9，consumer线程数是3， C0 ~ C2，那么每个线程都分配哪些分区呢？ C0 消费分区 0, 1, 2, 3 C1 消费分区 4, 5, 6 C2 消费分区 7, 8, 9 |
range |