参数名称 | 参数解释 |
---|---|
acks | acks指定了必须有多少个分区副本接收到了消息,生产者才会认为消息是发送成功的。
|
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的数。这样即使发生重试,也不会打乱消息的先后顺序。 |