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 间隔