八、Kafka生产者调优

个人专题目录

ActiviMQ专题

链路追踪

Dubbo专题

Docker专题

Git专题

Idea专题

Java阿里P6+必会专题

Java工具类

Kafka专题

Linux专题

Maven专题

Markdown专题

Mysql专题

Netty专题

Nginx专题

Openstack专题

Redis专题

Spring专题

SpringBoot专题

SpringCloud专题

Zookeeper专题

个人随笔专题

数据结构专题

单点登录专题

设计模式专题

架构优化专题


Kafka概述

Kafka集群部署

Kafka工作流程分析

Kafka API实战

Kafka producer拦截器(interceptor)

Kafka Streams

扩展

Kafka生产者调优

Kafka producer config

(Kafka 0.10.1 Documentation)

1. 基本配置

1.1 发送设置

缓冲、批、停留等如下说明。

1.1.1 buffer.memory(32MB)

生产者用该内存块缓存app要发送给kafka的记录(即消息),注意该内存并非生产者使用的所有内存。如果app发给客户端库的消息速率大于客户端库发给broker的速率,该内存buffer会填满,此处的行为,库会阻塞max.block.ms(1min),1min后,报异常。

1.1.2 batch.size(16KB)

客户端库 会把去往同一分区去的记录打成一批,注意一批是针对同一分区的吆。Size太小效率不高,当为0时,即禁用批的功能,另外,size太大就也不好,因停留的延迟是一定的(linger.ms),在此延迟内多半都达不到这个size,对应固定的buffer[size],是浪费的。

1.1.3 linger.ms(0)

在生产者重负载情况下,app到客户端库的消息速率大于客户端库到服务器的速率,生产者会使用批传输消息,甚至在生产者一般负载情况下,客户端库也想降低发送请求的次数,这个设置为此目的,当客户端库收到app的一条记录时候,并不立即发送出去,而是要等这个时间,以允许有更多的记录打成批送出去,类似nagle,这个时间就给了把多久的记录打成一批的上限。当然如果在等的过程中,满足了一批,就会立即送出去,不管该时间设置,然而如果一直不到一批(batchsize,如果负载很轻)就在该时间超时后送出,哪怕一个小批。

1.1.4 max.request.size(1MB)

生产者发送一次数据的最大大小(即一个kafka 格式的request,一个kafka protocol unit,在进入OS内核之前,一旦进入内核就是流了,因此服务器收到后,需要根据kafka自己的协议进行解析),一个request可以包括多个批,1个批可以包括多个记录(消息),因此本设置也暗指生产者所认为的一个记录的最大大小, 另外,服务器也有自己允许的一个记录的最大大小,该大小可以不同于此 max request size。 因为一个批有自己的最大大小(bashsize),因此本设置其实也是上限了在一次发送中批的数量。

1.1.5 max.in.flight.requests.per.connection(5)

每个连接上,允许多少在飞行中的request数,即发送了多少次,这些次至今未被确认,至今没有结果,这些次的数据可能在生产者的OS 内核中、可能在线上、可能在服务器的内核中、可能在kafka server app中但尚未被处理完,相当于 tcp sliding window中可以发送的数据大小。一旦超过这个发送次数,生产者的发送就被阻塞,为此阻塞多少时间没有说明。需要注意的是:如果这个发送次数设为大于1,即可以有至少两个发送在进行中,如果两次发送中都有一个批目标是相同分区、第一次发送失败、第二次发送成功,且开启失败重发的开关,这样就会导致记录的失序,在目标分区上的记录失序。

1.1.6 max.block.ms(1min)

如果内存满了(buffer memory 32M)或元数据不可用(比如:leader不可用),KafkaProducer.send()或KafkaProducer.partitionsFor()就会被阻塞,阻塞的时间就是 max block ms。

1.2 等待确认配置

1.2.1 acks(1)

​ 假定一个数据在集群存3份,分布在一个主片(即主分区)、两个从片(副本分区)上,主片存在于一个节点(简称点)上,两个从片可以分布在两个点上或一个点上。

​ 生产者发一个数据到某个主分所在的点上,该点处理完后,如果直接返回生产者,ack为1,如果两个从点,都返给主点,然后,主点返给生产者则ack为-1,ack为0即不要求服务端返回。

1.2.2 timeout.ms(30s)

为了1.1acks,主节点最长等待N个从节点的时间,如果acks=0、1,不用考虑该设置(此情况下,与从节点无关),其他需要考虑最长等待从节点多久为了来自从节点的确认,在此前从节点从主节点主动pull了数据(为了数据同步),从要对数据进行处理,处理到合适的地方,给主发确认。

如果超时后,主仍未收到正确的确认数目,就给生产者返回错误。

注意,此项仅为服务端使用。

1.2.3 request.timeout.ms(30s)

生产者等待响应的超时,在未超时时,如果没收到响应,生产者会重发该发送,如果重发次数用完了,则发送最终宣告失败。重发有关的:重发次数(retries),重发间隔(retry.backoff.ms:100ms)。

该项 包括 timeout.ms表示的子流程。

1.3 内核缓冲配置

1.3.1 send.buffer.bytes(128KB)

该socket内核SO_SNDBUF的大小。

1.3.2 receive.buffer.bytes(32KB)

该socket内核 SO_RCVBUF的大小。

1.4 集群元数据设置

1.4.1 metadata.fetch.timeout.ms(1min)

生产者第一次发送数据时,要取回该topic所有分区位于哪些节点上的元数据,需要最多多长时间达成这个动作,就是本项的目的,超时后,抛异常给生产者。

1.4.2 metadata.max.age.ms(5min)

生产者多久需要刷一次元数据,定时刷,第一次的获取通过 metadata fetch timeout流程。

1.5 连接设置

1.5.1 connections.max.idle.ms(9min)

生产者在最后一次发流量之后 多久关闭该连接。

1.5.2 reconnect.backoff.ms(50ms)

生产者重连间隔,如果上次连接失败。

1.6 重发请求设置

1.6.1 retry.backoff.ms(100ms)

生产者重发间隔,如果上次发送失败。

1.6.2 retries(0)

生产者发送失败时,最多重发次数,它>1与 max in flight requests per connection>1 配合时,可以导致 多次发送之间的失序, 对于 目标是 同分区的情况会导致 记录的的失序,当然,如果是有相同记录key的情况,会带来问题。

1.7 压缩设置

1.7.1 compression.type(none)

压缩源有两处可以设置:生产者、server,如果生产者开启压缩,你会注意到:变小了的生产者吐率和(或)更低的server压缩率,当收到压缩消息时,0.10.0server不会再压了,此举比再压相比会降低时延和提高吞吐率。然而,这会降低生产者的批大小(以前够一批的,一他妈压缩变半批了,又要马上送走),因此,这会导致更差的吞吐率,不过这没关系,可以调整linger(比如1ms)和batchsize,来提上去吞吐率。

此外,在生产者上压缩消息所用的内存buffer比在server上压缩消息所用的内存buffer小,因此,对于在logfile中压缩比来说,其实在生产者压缩不如在server上压缩更好,在未来版本中 这个用于压缩的 内存的大小 变成配置项。

另外,端到端的批量压缩概念,生产者压缩,server存log的是压缩之后东西,消费者解压缩,另外,最好让kafka压缩(不要使用跟kafka无关的压缩,需要kafka感知压缩才行,即可以生产者可以server),kafka可以批量压缩,批的越好压缩比越高,反之越差,切记。

1.8 加密设置

推荐阅读更多精彩内容

  • 不管是把 Kafka 作为消息队列、消息、总线还是数据存储平台来使用 ,总是需要有一个可以往 Kafka 写入数据...
    消失er阅读 4,152评论 0 3
  • 本章我们将会讨论Kafka生产者是如何发送消息到Kafka的。Kafka项目有一个生产者客户端,我们可以通过这个客...
    __豆约翰__阅读 816评论 1 1
  • 前言 看完本文你将学会以下知识: kafka 数据的生产大致流程 如何创建并使用 kafka生产者 kafka生产...
    code_solve阅读 2,357评论 1 6
  • 1. kafka 生产者发送消息的流程 2. Kafka 生产者发送数据的3种方式 (1) 发送并忘记(fire-...
    CoderJed阅读 1,686评论 0 1
  • kafka的定义:是一个分布式消息系统,由LinkedIn使用Scala编写,用作LinkedIn的活动流(Act...
    时待吾阅读 3,050评论 1 15