大数据与Kafka系列之kafka消费者各种启动参数说明

建立一个普通的消费者。

public static void CommonDemo() {
        final Properties properties = new Properties() {{
            put("bootstrap.servers", "localhost:9092");
            put("group.id", "testAPIdemo");
            put("enable.auto.commit", "true");
            put("auto.commit.interval.ms", "5000");
            put("session.timeout.ms", "30000");
            put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
            put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
            put("auto.offset.reset","latest");
        }};
        //自动提交，会有问题
        //1.默认会5秒提交一次offset，但是中间停止的话会造成重复消费
        //2.新添加进消费者组的时候，会再均衡，默认从上次消费提交的地方开始，消息重复
        //3.自动提交，虽然提交了偏移量，但并不知道，哪些消息被处理了，是否处理成功，偏移量是否提交成功
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties);
        consumer.subscribe(Arrays.asList("testAPI"));
        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(100);
            for (ConsumerRecord<String, String> record : records) {
                record.toString();
                logger.info("Consumer  "+record.topic()+"   "+record.partition()+"   "+record.offset()+"  "+record.value());
            }
        }
    }

消费者的启动参数如下所示：

2018-06-19 17:34:24,244 - Kafka version : 0.10.2.0
2018-06-19 17:34:24,244 - Kafka commitId : 576d93a8dc0cf421
2018-06-19 17:34:26,906 - ConsumerConfig values: 
	auto.commit.interval.ms = 5000
	auto.offset.reset = latest
	bootstrap.servers = [localhost:9092]
	check.crcs = true
	client.id = 
	connections.max.idle.ms = 540000
	enable.auto.commit = true
	exclude.internal.topics = true
	fetch.max.bytes = 52428800
	fetch.max.wait.ms = 500
	fetch.min.bytes = 1
	group.id = testAPIdemo
	heartbeat.interval.ms = 3000
	interceptor.classes = null
	key.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
	max.partition.fetch.bytes = 1048576
	max.poll.interval.ms = 300000
	max.poll.records = 500
	metadata.max.age.ms = 300000
	metric.reporters = []
	metrics.num.samples = 2
	metrics.recording.level = INFO
	metrics.sample.window.ms = 30000
	partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
	receive.buffer.bytes = 65536
	reconnect.backoff.ms = 50
	request.timeout.ms = 305000
	retry.backoff.ms = 100
	sasl.jaas.config = null
	sasl.kerberos.kinit.cmd = /usr/bin/kinit
	sasl.kerberos.min.time.before.relogin = 60000
	sasl.kerberos.service.name = null
	sasl.kerberos.ticket.renew.jitter = 0.05
	sasl.kerberos.ticket.renew.window.factor = 0.8
	sasl.mechanism = GSSAPI
	security.protocol = PLAINTEXT
	send.buffer.bytes = 131072
	session.timeout.ms = 30000
	ssl.cipher.suites = null
	ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
	ssl.endpoint.identification.algorithm = null
	ssl.key.password = null
	ssl.keymanager.algorithm = SunX509
	ssl.keystore.location = null
	ssl.keystore.password = null
	ssl.keystore.type = JKS
	ssl.protocol = TLS
	ssl.provider = null
	ssl.secure.random.implementation = null
	ssl.trustmanager.algorithm = PKIX
	ssl.truststore.location = null
	ssl.truststore.password = null
	ssl.truststore.type = JKS
	value.deserializer = class org.apache.kafka.common.serialization.StringDeserializer

auto.commit.interval.ms

如果enable.auto.commit设置为，则消费者偏移量自动提交给Kafka的频率（以毫秒为单位）true。

auto.offset.reset

在Kafka中没有初始偏移量或者当前偏移量在服务器上不再存在时要执行的操作（例如，因为该数据已被删除）：

1. earliest：自动将偏移重置为最早的偏移量
2. latest：自动将偏移重置为最新的偏移量
3. none：如果消费者组没有找到先前的偏移量，则向消费者抛出异常 4 anything else：向消费者抛出异常。

bootstrap.servers

用于建立到Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器，而不管在此指定哪些服务器用于引导 - 此列表仅影响用于发现全套服务器的初始主机。该列表应该以表格的形式出现host1:port1,host2:port2,...。由于这些服务器仅用于初始连接以发现完整的群集成员资格（可能会动态更改），因此此列表不需要包含全套服务器（但您可能需要多个服务器） 。

check.crcs

自动检查所消耗记录的CRC32。这可以确保没有线上或磁盘损坏的消息发生。此检查会增加一些开销，因此在寻求极高性能的情况下可能会被禁用。

client.id

发出请求时传递给服务器的id字符串。这样做的目的是通过允许将逻辑应用程序名称包含在服务器端请求日志中，从而能够跟踪ip / port之外的请求源，不添加的话后台会默认生成一个。

connections.max.idle.ms

在此配置指定的毫秒数后关闭空闲连接。

enable.auto.commit

如果为true，则消费者的偏移量将在后台定期提交。

exclude.internal.topics

内部主题（如偏移量）的记录是否应暴露给消费者。如果设置为true从内部主题接收记录的唯一方法是订阅它。

fetch.max.bytes

服务器为获取请求返回的最大数据量。记录由消费者批量提取，如果提取的第一个非空分区中的第一个记录批次大于此值，则记录批次仍将返回以确保消费者可以取得进展。因此，这不是绝对的最大值。代理接受的最大记录批量大小通过message.max.bytes（代理配置）或max.message.bytes（主题配置）进行定义。请注意，消费者并行执行多个提取。

fetch.max.wait.ms

如果没有足够的数据立即满足fetch.min.bytes给出的要求，服务器在应答提取请求之前将阻塞的最大时间量。

fetch.min.bytes

服务器为获取请求返回的最小数据量。如果数据不足，请求会在回复请求之前等待那么多的数据累积。

group.id

标识此消费者所属的Connect群集组的唯一字符串。

heartbeat.interval.ms

在使用Kafka的团队管理设施时，心跳与团队协调员之间的预期时间。心跳信号用于确保工作人员的会话保持活动状态，并便于在新成员加入或离开组时重新平衡。该值必须设置为低于session.timeout.ms，但通常应设置为不高于该值的1/3。它可以调整得更低，以控制正常再平衡的预期时间。

interceptor.classes

用作拦截器的类的列表。通过实现org.apache.kafka.clients.producer.ProducerInterceptor接口，您可以在生产者发布到Kafka集群之前拦截（并可能会改变）生产者收到的记录。默认情况下，没有拦截器。produce端有一个拦截器，消费者请求结果返回也可以有一个拦截器。

key.deserializer

用于实现org.apache.kafka.common.serialization.Deserializer接口的密钥的反序列化器类。

max.partition.fetch.bytes

服务器将返回每个分区的最大数据量。记录由消费者批量提取。如果提取的第一个非空分区中的第一个记录批次大于此限制，则仍会返回该批次以确保用户可以取得进展。代理接受的最大记录批量大小通过message.max.bytes（代理配置）或max.message.bytes（主题配置）进行定义。有关限制消费者请求大小的信息，请参阅fetch.max.bytes。

max.poll.interval.ms

使用消费者组管理时，poll（）的调用之间的最大延迟。这提供了消费者在获取更多记录之前可以空闲的时间量的上限。如果在此超时到期之前未调用poll（），则认为使用者失败，并且该组将重新平衡以便将分区重新分配给其他成员。

max.poll.records

在一次调用poll（）中返回的最大记录数。

metadata.max.age.ms

以毫秒为单位的时间段之后，即使我们没有看到任何分区领导改变以主动发现任何新代理或分区，我们强制更新元数据。

partition.assignment.strategy

在用于将分区分配给消费者流的“范围”或“循环”策略之间进行选择。

循环分区分配器将所有可用的分区和所有可用的使用者线程放在一起。然后继续执行从分区到消费者线程的循环分配。如果所有消费者实例的订阅都是相同的，那么分区将被均匀分配。（即所有消费者线程中的分区所有权计数将在一个正好为1的增量内）。只有在以下情况下才允许循环分配：（a）每个主题在消费者实例中具有相同数量的流（b）的订阅主题对于组内的每个消费者实例都是相同的。

范围分区在每个主题的基础上工作。对于每个主题，我们按数字顺序排列可用的分区，并按照字典顺序排列消费者线程。然后，我们将分区数除以消费者流（线程）的总数，以确定分配给每个消费者的分区数。如果它不均匀分配，那么前几个消费者将有一个额外的分区。

metric*

与kafka自身指标相关，后面再提。

receive.buffer.bytes

读取数据时使用的TCP接收缓冲区（SO_RCVBUF）的大小。如果该值为-1，则将使用操作系统默认值。

reconnect.backoff.ms

尝试重新连接到给定主机之前等待的基本时间。这避免了在紧密循环中重复连接到主机。该退避适用于客户端向经纪人的所有连接尝试。

request.timeout.ms

该配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，客户端将在必要时重新发送请求，或者如果重试耗尽，请求失败。

retry.backoff.ms

尝试重试对给定主题分区的失败请求之前等待的时间量。这可以避免在某些故障情况下重复发送请求。

sasl*&ssl

kafka安全相关，后面再提。