kafka生产者Producer参数设置及参数调优建议-kafka 商业环境实战

kafka商业环境实战系列

本套系列博客从真实商业环境抽取案例进行总结和分享，并给出kafka商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。版权声明：本套kafka调优系列版权归做者(秦凯新)全部，禁止转载，欢迎学习。

做者：秦凯新 地址：于深圳

• kafka 商业环境实战-kafka生产环境规划
• kafka 商业环境实战-kafka生产者和消费者吞吐量测试
• kafka 商业环境实战-kafka生产者Producer参数设置及参数调优建议

1. Producer核心工做流程

• Producer首先使用用户主线程将待发送的消息封装进一个ProducerRecord类实例中。
• 进行序列化后，发送给Partioner，由Partioner肯定目标分区后，发送到Producer程序中的一块内存缓冲区中。
• Producer的另外一个工做线程（即Sender线程），则负责实时地从该缓冲区中提取出准备好的消息封装到一个批次的内，统一发送给对应的broker中。

2. producer 主要参数设置

2.1 producer 参数acks 设置（无数据丢失）

在消息被认为是“已提交”以前，producer须要leader确认的produce请求的应答数。该参数用于控制消息的持久性，目前提供了3个取值：

acks = 0: 表示produce请求当即返回，不须要等待leader的任何确认。这种方案有最高的吞吐率，可是不保证消息是否真的发送成功。

acks = -1: 表示分区leader必须等待消息被成功写入到全部的ISR副本(同步副本)中才认为produce请求成功。这种方案提供最高的消息持久性保证，可是理论上吞吐率也是最差的。

acks = 1: 表示leader副本必须应答此produce请求并写入消息到本地日志，以后produce请求被认为成功。若是此时leader副本应答请求以后挂掉了，消息会丢失。这是个这种的方案，提供了不错的持久性保证和吞吐。

商业环境推荐：

若是要较高的持久性要求以及无数据丢失的需求，设置acks = -1。其余状况下设置acks = 1

2.2 producer参数 buffer.memory 设置（吞吐量）

该参数用于指定Producer端用于缓存消息的缓冲区大小，单位为字节，默认值为：33554432合计为32M。kafka采用的是异步发送的消息架构，prducer启动时会首先建立一块内存缓冲区用于保存待发送的消息，而后由一个专属线程负责从缓冲区读取消息进行真正的发送。

商业环境推荐：

• 消息持续发送过程当中，当缓冲区被填满后，producer当即进入阻塞状态直到空闲内存被释放出来，这段时间不能超过max.blocks.ms设置的值，一旦超过，producer则会抛出TimeoutException 异常，由于Producer是线程安全的，若一直报TimeoutException，须要考虑调高buffer.memory 了。
• 用户在使用多个线程共享kafka producer时，很容易把 buffer.memory 打满。

2.3 producer参数 compression.type 设置（lZ4）

producer压缩器，目前支持none（不压缩），gzip，snappy和lz4。

商业环境推荐：

基于公司物联网平台，试验过目前lz4的效果最好。固然2016年8月，FaceBook开源了Ztandard。官网测试： Ztandard压缩率为2。8，snappy为2.091，LZ4 为2.101 。

2.4 producer参数 retries设置(注意消息乱序,EOS)

producer重试的次数设置。重试时producer会从新发送以前因为瞬时缘由出现失败的消息。瞬时失败的缘由可能包括：元数据信息失效、副本数量不足、超时、位移越界或未知分区等。假若设置了retries > 0，那么这些状况下producer会尝试重试。

商业环境推荐：

• producer还有个参数：max.in.flight.requests.per.connection。若是设置该参数大约1，那么设置retries就有可能形成发送消息的乱序。
• 版本为0.11.1.0的kafka已经支持"精确到一次的语义”，所以消息的重试不会形成消息的重复发送。

2.5 producer参数batch.size设置(吞吐量和延时性能)

producer都是按照batch进行发送的，所以batch大小的选择对于producer性能相当重要。producer会把发往同一分区的多条消息封装进一个batch中，当batch满了后，producer才会把消息发送出去。可是也不必定等到满了，这和另一个参数linger.ms有关。默认值为16K，合计为16384.

商业环境推荐：

• batch 越小，producer的吞吐量越低，越大，吞吐量越大。

2.6 producer参数linger.ms设置(吞吐量和延时性能)

producer是按照batch进行发送的，可是还要看linger.ms的值，默认是0，表示不作停留。这种状况下，可能有的batch中没有包含足够多的produce请求就被发送出去了，形成了大量的小batch，给网络IO带来的极大的压力。

商业环境推荐：

• 为了减小了网络IO，提高了总体的TPS。假设设置linger.ms=5，表示producer请求可能会延时5ms才会被发送。

2.7 producer参数max.in.flight.requests.per.connection设置(吞吐量和延时性能)

producer的IO线程在单个Socket链接上可以发送未应答produce请求的最大数量。增长此值应该能够增长IO线程的吞吐量，从而总体上提高producer的性能。不过就像以前说的若是开启了重试机制，那么设置该参数大于1的话有可能形成消息的乱序。

商业环境推荐：

• 默认值5是一个比较好的起始点,若是发现producer的瓶颈在IO线程，同时各个broker端负载不高，那么能够尝试适当增长该值.
• 过大增长该参数会形成producer的总体内存负担，同时还可能形成没必要要的锁竞争反而会下降TPS

结语

秦凯新 于深圳 2018-10-27