根据实际业务场景,客户端参数配置适当的值,客户端参数列表及说明如下所示:
表1.生产者客户端
参数 | 说明 |
---|---|
retries | 消息发送失败时的重试次数。 |
retry.backoff.ms | 消息发送失败时的重试间隔,建议设置为1000。单位:毫秒。 |
acks | 发送消息的持久化机制。为了提升发送性能, 建议设置为acks=1。acks=0:无需服务端的Response,性能较高、丢数据风险较大。acks=1:服务端主节点写成功即返回Response,性能中等、丢数据风险中等、主节点宕机可能导致数据丢失。acks=all:服务端主节点写成功且备节点同步成功才返回Response,性能较差、数据较为安全、主节点和备节点都宕机才会导致数据丢失。 |
batch.size | 发往每个分区的消息缓存量。达到设置的数值时,就会触发一次网络请求,然后Producer客户端把消息批量发往服务器。如果batch.size设置过小,有可能影响发送性能和稳定性。建议保持默认值16384。单位:字节。 |
linger.ms | 每条消息在缓存中的最长时间。若超过这个时间,Producer客户端就会忽略batch.size的限制,立即把消息发往服务器。建议根据业务场景, 将linger.ms设置在100~1000之间。单位:毫秒。 |
partitioner.class | 设置分区策略。建议采用粘性分区策略,可提升发送性能。发送客户端2.4及以上版本,默认采用粘性分区策略模式。 |
buffer.memory | 发送的内存池大小。如果内存池设置过小,则有可能导致申请内存耗时过长,从而影响发送性能,甚至导致发送超时。建议buffer.memory ≧ batch.size * 分区数 * 2。单位:字节。 |
表2.消费者客户端参数
参数 | 说明 |
---|---|
fetch.min.bytes | 消费者从服务端获取数据的最小字节数。设置该参数时请尽量评估消息发送端的消息量,若设置过大可能会导致消费端延迟增大,过小可能会导致消费端频繁拉取消息。单位:字节。 |
fetch.max.wait.ms | 服务端等待的最大时间。单位:毫秒。如果使用Local存储引擎,配置了fetch.min.bytes参数,服务器会等待足够的数据才会返回。超过此时间即使没有足够数据也会返回。如果是云存储引擎,一旦有新数据发送进来, 服务器就会结束等待,不需要等待fetch.min.bytes的值。 |
max.partion.fetch.bytes | 每个分区返回的最大字节数。单位:字节。 |
session.timeout.ms | 消费端发送心跳的时间间隔,如果在心跳时间间隔内没有发送心跳,则服务端会认为消费者死亡,从而触发Rebalance,Rebalance期间客户端将会停止消费数据等待Rebalance完成。建议将此参数设置为30000-60000。单位:毫秒。默认有效值:6000-300000。 |
max.poll.records | 每次Poll获取的最大消息数量,若此值设置过大则需要尽快处理业务逻辑,避免处理过慢影响下一次Poll数据,从而导致在session.timeout.ms时间内没有发送心跳引起Rebalance。建议该值小于<单个线程每秒消费的条数> * <消费线程的个数> *的值。重要 在Java Client 0.10.1及其以上版本有单独的线程发送心跳,小于此版本或者其他语言的客户端都需考虑处理数据时间和发送心跳的间隔,防止频繁Rebalance影响正常消费。 |
max.poll.interval.ms | 最大的Poll间隔时间,仅在Java Client 0.10.1及其以上版本需配置该参数。如果在间隔时间内消费者没有发送Poll请求,即使在session.timeout.ms参数设置的时间内发送了心跳。服务端也会认为消费者死亡,从而触发Rebalance。因此需注意此值需要合理设置,建议该值大于<消费一条消息花费的时间> *的值。通常使用默认值即可。单位:毫秒。默认值:300000。 |
enable.auto.commit | 是否采用自动提交位点机制。true:默认采用自动提交机制。false:不采用自动提交机制。默认值:true。 |
auto.commit.interval.ms | 自动提交位点时间间隔。默认值为1000,单位:毫秒。 |
auto.offset.reset | 消费位点重置策略。latest:从最大位点开始消费。earliest:从最小位点开始消费。none:不做任何操作,即不重置。说明建议设置成latest,而不要设置成earliest,避免因位点非法时从头开始消费,从而造成大量重复。如果是您自己管理位点,可以设置为none。 |