java api kafka配置信息分析

producer 配置可选参数

acks

配置表示 producer 发送消息到 broker 上以后的确认值。有三个可选项

1. acks=0表示 producer 不需要等待 broker 的消息确认，发出消息那么就认为消息已成功写入Kafka，时效率高，但同时风险最大，server 宕机时，数据将会丢失

2. acks=1 表示 producer 只需要获得 kafka 集群中的 leader 节点确认即可，这个选择时延较小同时确保了 leader 节点确认接收成功

3. acks=all leader 节点在返回确认或错误响应之前，会等待所有同步副本都收到消息。如果和min.insync.replicas参数结合起来，就可以决定在返回确认前至少有多个副本能够收到消息。比如min.insync.replicas=1就需要至少一个follwer确认收到消息。相对安全，但是效率较低。但是由于 ISR 可能会缩小到仅包含一个 Replica，所以设置参数为all并不能一定避免数据丢失

batch.size

生产者发送多个消息到 broker 上的同一个分区时，为了减少网络请求带来的性能开销，通过批量的方式来提交消息，可以通过这个参数来控制批量提交的字节数大小，默认大小是 16384byte,也就是 16kb，意味着当一批消息大小达到指定的 batch.size 的时候会统一发送

linger.ms

Producer 默认会把两次发送时间间隔内收集到的所有 Requests 进行一次聚合然后再发送，以此提高吞吐量，而 linger.ms 就是为每次发送到 broker 的请求增加一些 delay，以此来聚合更多的 Message 请求。这个有点想 TCP 里面的 Nagle 算法，在 TCP 协议的传输中，为了减少大量小数据包的发送，采用了 Nagle 算法，也就是基于小包的等-停协议。

默认情况即使缓冲区有剩余的空间，也会立即发送请求，设置一段时间用来等待从而将缓冲区填的更多，单位为毫秒，producer发送数据会延迟1ms，可以减少发送到kafka服务器的请求数据

batch.size 和 linger.ms 这两个参数是 kafka 性能优化的关键参数当二者都配置的时候，只要满足其中一个要求，就会发送请求到 broker 上

max.request.size

设置请求的数据的最大字节数，为了防止发生较大的数据包影响到吞吐量，默认值为 1MB

consumer配置可选参数

group.id

当producer发送一条消息，相同group.id的多个consumer只有其中一个consumer能消费到

(比如 topic=hehe的主题发送了一条消息，group.id=666的组，有三个消费者监听了这个主题，但这条消息只会被其中一个consumer消费到)，group.id=999的一个consumer也能消费这条消息。

enable.auto.commit

消费者消费消息以后自动提交，只有当消息提交以后，该消息才不会被再次接收到，还可以配合 auto.commit.interval.ms 控制自动提交的频率。当然，我们也可以通过 consumer.commitSync()的方式实现手动提交

auto.offset.reset

这个参数是针对新的 groupid 中的消费者而言的，当有新 groupid 的消费者来消费指定的 topic 时，对于该参数的配置，会有不同的语义

auto.offset.reset=latest 情况下，新的消费者将会从其他消费者最后消费的 offset 处开始消费 Topic 下的消息

auto.offset.reset= earliest 情况下，新的消费者会从该 topic 最早的消息开始消费

auto.offset.reset=none 情况下，新的消费者加入以后，由于之前不存在 offset，则会直接抛出异常。

max.poll.records

此设置限制每次调用 poll 返回的消息数，这样可以更容易的预测每次 poll 间隔要处理的最大值。通过调整此值，可以减少 poll 间隔

Kafka java api参数说明