kafka-producer配置参数

kafka配置参数详解
参数名称 参数解释
acks

acks指定了必须有多少个分区副本接收到了消息,生产者才会认为消息是发送成功的。

  1. acks=0,生产者成功写入消息之前不会等待来自任何服务器的响应,这种配置,提高吞吐量,但是消息存在丢失风险。
  2. acks=1,只要集群的leader(master)收到了消息,生产者将会受到发送成功的一个响应,如果消息无撞到达首领节点(比如首领节点崩愤,新的首领还没有被选举出来),生产者会收到一个错误响应,为了避免数据丢失,生产者会重发消息。不过,如果一个没有收到消息的节点成为新首领,消息还是会丢失。这个时候的吞吐量取决于使用的是
    同步发送还是异步发送。如果让发送客户端等待服务器的响应(通过调用Futu re 对象的get()方法,显然会增加延迟(在网络上传输一个来回的延迟)。如果客户端使用回调,延迟问题就可以得到缓解,不过吞吐量还是会受发送中消息数量的限制(比如,生产者在收到服务器响应之前可以发送多少个消息)。
  3. acks=all,所有参与复制的节点全部收到消息的时候,生产者才会收到来自服务器的一个响应,这种模式最安全,但是吞吐量受限制,它可以保证不止一个服务器收到消息,就算某台服务器奔溃,那么整个集群还是会正产运转。
buffer.memory

该参数用来设置生产者内存缓冲区的大小,缓冲生产者发往服务器的消息,如果生产者发送速率大于服务器接受速率,那么会导致生产者内存空间不足,此时send方法要么阻塞,要么爬出异常,具体行为依赖于,block.on.buffer.full参数,0.9.0.0版本中被替换成了max.block.ms用来设置抛出异常之前可以阻塞一段时间。

compression.type 消息压缩算法,snappy消耗较低的CPU并且有较为理想的压缩比和压缩性能,如果对于性能和网络带宽,这是一种比较理想的算法(Google发明的算法,Google是真牛逼),gzip算法耗费CPU资源比较多,但是提高了很高的压缩比,如果对于网络带宽有着很高的要求,那么这种算法比较适合。使用压缩可以降低网络传输开销和存储开销,这也往往是向kafka发送消息的瓶颈所在。
retries 生产者从服务器收到的错误消息有可能是临时的,当生产者收到服务器发来的错误消息,会启动重试机制,当充实了n(设置的值)次,还是收到错误消息,那么将会返回错误。生产者会在每次重试之间间隔100ms,不过可以通过retry.backoff.ms改变这个间隔。
batch.size 当多个消息发往 同一个分区,生产者会将他们放进同一个批次,该参数指定了一个批次可以使用的内存大小,按照字节数进行计算,不是消息个数,当批次被填满,批次里面所有得消息将会被发送,半满的批次,甚至只包含一个消息也可能会被发送,所以即使把批次设置的很大,也不会造成延迟,只是占用的内存打了一些而已。但是设置的太小,那么生产者将会频繁的发送小,增加一些额外的开销。
linger.ms 该参数指定了生产者在发送批次之前等待更多消息加入批次的时间。KafkaPr oduce 「会在
批次填满或linger.ms达到上限时把批次发送出去。默认情况下,只要有可用的线程, 生
产者就会把消息发送出去,就算批次里只有一个消息。把linger.ms设置成比0 大的数,
让生产者在发送批次之前等待一会儿,使更多的消息加入到这个批次。虽然这样会增加延
迟,但也会提升吞吐量(因为一次性发送更多的消息,每个消息的开销就变小了)
client.id 服务器会根据该参数值来识别消息的来源,还可以用在日志配置以及配额指标里
max.in.flight.requests.per.connection 指定了生产者收到服务器响应之前可以发送多少个消息。它的值越高,将会消耗更多的内存,不过也会提升吞吐量。设置为1,可以保证消息是按照发送的顺序写入服务器。即使发生了重试。
timeout.ms 指定了broker等待同步副本返回消息的时间,如果指定时间同步副本没有返回消息,那么将会返回错误。
requests.timeout.ms 生产者发送数据时等待服务器返回响应的时间
metadata.fetch.timeout.ms 生产者在获取元数据(例如分区首领是谁?)时等待服务器的响应时间,如果响应时间接收不到消息,那么要么重试要么返回一个错误(抛出异常或者执行回调)
max.block.ms 该参数指定了在调用send()方法或使用partitionFor() 方法获取元数据时生产者的阻塞
时间。当生产者的发送缓冲区已满,或者没有可用的元数据时,这些方法就会阻塞。在阻
塞时间达到max.block.ms 时,生产者会抛出超时异常。
max.request.size 控制生产者发送消息的大小,它可以指定单个消息的最大值,也可以指定单个请求里所有消息大小的总和。比如1MB,那么单个消息最大大小是1MB,同时如果消息大小是1KB,那么一次可以发送1000条消息。另外broker也有接受消息最大的限制,message.max.bytes,(参考博主的broker配置文章)所以两边最好能够匹配。避免生产者发送消息被broker拒绝。

receive.buffer.bytes

send. buffer.bytes

这两个参数分别指定了TCP socket 接收和发送数据包的缓冲区大小。如果它们被设为-1 ,
就使用操作系统的默认值。如果生产者或消费者与broker 处于不同的数据中心,那么可以
适当增大这些值,因为跨数据中心的网络一般都有比较高的延迟和比较低的带宽。
kafka可以保证一个分区内的消息是有序的,如果生产者按照一定的顺序发送消息,那么broker会按照这个顺序将他们写到分区中,消费者也会按照同样的顺序消费他们,但是!如果设置了retries大于1,而设置了max.in.flight.requests.per.connection也是大于1的数,比如是2,那么。。当消息批次1发送之后,尚未收到服务器的响应,此时消息批次2也被发送,但是,消息批次1失败了,消息批次2成功了,那么此时由于retries设置了大于1的数,所以出发了重试机制,那么消息批次1开始进行重试发送,此时假设消息批次1发送成功了,那么这样的话,尽管消息发送的顺序是:消息批次1,消息批次2,但是最终服务端的顺序确实消息批次2,消息批次1。顺序被打乱了。。。所以如果对于顺序有着严格要求,最好将 max.in.flight.requests.per.connection 设置为1,将retries设置大于1的数。这样即使发生重试,也不会打乱消息的先后顺序。

 

你可能感兴趣的:(kafka,大数据,java,消息队列)