本文主要针对消费者中几个比较重要的、常用的与性能相关的参数进行粗略的解释
enable.auto.commit
默认为true
指定消费者是否自动提交偏移量,如果设置为自动提交,那么消息的提交由kafka帮我们保证,可以减少消费者处理时的一些问题,但是自动提交的缺点是可能会造成消息丢失,比如消费端获取了一些消息后,此时服务端就确认当前消息已经被消费了,但是如果消费端这是突然挂了,那么这些消息实际上还未真正的消费,当消费端重新上线后,服务端也不会再重新发送这些消息了。
如果要避免上述问题,我们就需要自己控制消息的提交,那么可以设置为false,需要注意一定要确保消息执行到手动提交的部分,比如放到finally代码块中,否则消息任可能会被重复消费。
auto.commit.interval.ms
默认为5s
当设置自动提交偏移量时,此参数用来设置自动提交的频率。
auto.offset.reset
默认值是latest
当消费者读取到一个无效偏移量或者偏移量被删除,一种是latest,从最新记录读取数据(消费者启动后接收到数据),另一个值是earliest,从起始位置读取数据。
session.timeout.ms
默认是10s
表示当前消费者如果在指定时间内没有向服务端发送心跳则被认为死亡,将触发协调器发出分区再平衡,此参数可以适当设置大一些,以免由于网络抖动或者垃圾收集造成触发分区再平衡,不过如果设置太大,也会造成监测到故障节点不及时。
需要注意,该值必须在broker配置中group.min.session.timeout.ms与group.max.session.timeout.ms的范围内。
heartbeat.interval.ms
默认是3s
这个参数配合上面一个使用,消费者向服务端发送心跳的频率,一般不能高于session.timeout.ms的三分之一,甚至更低,以控制正常再平衡的预期时间。
max.partition.fetch.bytes
默认为1M
服务端从每个分区里返回给消费者的最大字节数,也就是消费者fetch能拉取到的最大字节数。
- 此参数要配合broker的max.message.size设置,如果设置的比max.message.size小,那么消费者就可能无法正常读取到消息,比如broker能够读取到了2M的数据,但是消费者最大只能接受1M,这就造成了问题。
- 如果fetch的第一个非空分区中的第一个记录批大于此限制,则仍将返回该批以确保使用者能够取得进展
- 内存问题,假如有10个分区,每个分区可接收2M,那么如果当只有一个消费者时,这一个消费者就必须至少有20M内存。
- 另外如果这个值设置的过大就还得注意消费者一次fetch时间可能会过长的问题。
fetch.max.bytes
默认为50m
服务器应为获取请求返回的最大数据量,这不是绝对的最大值,如果获取的第一个非空分区中的第一条消息大于此值,则仍将返回该消息以确保使用者能够取得进展。broker接受的最大消息大小是通过message.max.bytes(broker配置)或max.message.bytes(topic配置)定义的。请注意,消费者并行执行多个fetches。
fetch.min.bytes
默认为1字节
服务器应为获取请求返回的最小数据量,如果broker发现数据量小于这个值,那么将等待有足够的数据再返回给消费者,调高此值,可以一些额外的延迟获得较高的服务器吞吐量。
fetch.max.wait.ms
默认500ms
如果没有足够的数据立即满足fetch.min.bytes给定的要求,则服务器在回答fetch请求之前将阻塞的最长时间。
max.poll.records
默认为500条
在对poll()的单个调用中返回的最大记录数。
max.poll.interval.ms
默认30s
使用消费者组管理时调用poll()之间的最大延迟。这为消费者在获取更多消息之前可以空闲的时间设置了上限。如果在此超时过期之前未调用poll(),则认为消费者出现了故障,该组将发生分区再平衡,以便将分区重新分配给另一个成员。
需要注意设置的太小可能会造成意外的分区再平衡。
partition.assignment.strategy
默认为RangeAssignor
分区分配的策略。
- RangeAssignor:该策略会把主题的若干个连续的分区分配给消费者。
- RoundRobinAssignor:该策略把主题的所有分区逐个分配给消费者。
- 当然还可以自定义分配策略。
假设有主题t0和t1,每个主题分别有3个分区,还有2个消费者c0和c1。
按照RangeAssignor的分配方式,最终的结果为:
按照RangeAssignor的分配方式,最终的结果为: