Kafka生产者Producer常用参数

下面先来个Producer生产者的Demo案例：

import org.apache.kafka.clients.producer.Callback;import org.apache.kafka.clients.producer.KafkaProducer;import org.apache.kafka.clients.producer.ProducerRecord;import org.apache.kafka.clients.producer.Recordmetadata;public class ProducerDemo { public static void main(String[] args) throws Exception { Properties props = new Properties();// 这里可以配置几台broker即可，他会自动从broker去拉取元数据进行缓存 props.put("bootstrap.servers", "hadoop03:9092,hadoop04:9092,hadoop05:9092");// 这个就是负责把发送的key从字符串序列化为字节数组 props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");// 这个就是负责把你发送的实际的message从字符串序列化为字节数组 props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("acks", "-1"); props.put("retries", 3); props.put("batch.size", 323840); props.put("linger.ms", 10); props.put("buffer.memory", 33554432); props.put("max.block.ms", 3000);// 创建一个Producer实例：线程资源，跟各个broker建立socket连接资源 KafkaProducer producer = new KafkaProducer(props); ProducerRecord record = new ProducerRecord<>( "test-topic", "test-key", "test-value");```// 这是异步发送的模式 producer.send(record, new Callback() { @Override public void onCompletion(Recordmetadata metadata, Exception exception) { if (exception == null) {// 消息发送成功 System.out.println("消息发送成功"); } else {// 消息发送失败，需要重新发送 } } }); Thread.sleep(10 * 1000);// 这是同步发送的模式// producer.send(record).get();// 你要一直等待人家后续一系列的步骤都做完，发送消息之后// 有了消息的回应返回给你，你这个方法才会退出来 producer.close(); }}

1 常见异常处理 LeaderNotAvailableException：这个就是如果某台机器挂了，此时leader副本不可用，会导致你写入失败，要等待其他follower副本切换为leader副本之后，才能继续写入，此时可以重试发送即可。如果说你平时重启kafka的broker进程，肯定会导致leader切换，一定会导致你写入报错，是LeaderNotAvailableExceptionNotControllerException：这个也是同理，如果说Controller所在Broker挂了，那么此时会有问题，需要等待Controller重新选举，此时也是一样就是重试即可NetworkException：网络异常，重试即可我们之前配置了一个参数，retries，他会自动重试的，但是如果重试几次之后还是不行，就会提供Exception给我们来处理了。

参数：retries 默认值是3
参数：retry.backoff.ms 两次重试之间的时间间隔

2 提升消息吞量

buffer.memory：设置发送消息的缓冲区，默认值是33554432，就是32MB
如果发送消息出去的速度小于写入消息进去的速度，就会导致缓冲区写满，此时生产消息就会阻塞住，所以说这里就应该多做一些压测，尽可能保证说这块缓冲区不会被写满导致生产行为被阻塞住

Long startTime=System.currentTime(); producer.send(record, new Callback() { @Override public void onCompletion(Recordmetadata metadata, Exception exception) { if(exception == null) {// 消息发送成功 System.out.println("消息发送成功"); } else {// 消息发送失败，需要重新发送 } } }); Long endTime=System.currentTime(); If(endTime - startTime > 100){//说明内存被压满了 说明有问题 }

compression.type，默认是none，不压缩，但是也可以使用lz4压缩，效率还是不错的，压缩之后可以减小数据量，提升吞吐量，但是会加大producer端的cpu开销batch.size，设置每个batch的大小，如果batch太小，会导致频繁网络请求，吞吐量下降；如果batch太大，会导致一条消息需要等待很久才能被发送出去，而且会让内存缓冲区有很大压力，过多数据缓冲在内存里,默认值是：16384，就是16kb，也就是一个batch满了16kb就发送出去，一般在实际生产环境，这个batch的值可以增大一些来提升吞吐量，可以自己压测一下linger.ms，这个值默认是0，意思就是消息必须立即被发送，但是这是不对的，一般设置一个100毫秒之类的，这样的话就是说，这个消息被发送出去后进入一个batch，如果100毫秒内，这个batch满了16kb，自然就会发送出去。但是如果100毫秒内，batch没满，那么也必须把消息发送出去了，不能让消息的发送延迟时间太长，也避免给内存造成过大的一个压力3 请示超时

max.request.size：这个参数用来控制发送出去的消息的大小，默认是1048576字节，也就1一般太小了，很多消息可能都会超过1mb的大小，所以需要自己优化调整，把他设置更大一些（企业成10M）request.timeout.ms：这个就是说发送一个请求出去之后，他有一个超时的时间限制，默认是如果30秒都收不到响应，那么就会认为异常，会抛出一个TimeoutException来让我们进行处理4 ACK参数

acks参数，其实是控制发送出去的消息的持久化机制的

1）如果acks=0，那么producer根本不管写入broker的消息到底成功没有，发送一条消息出去，立马就可以发送下一条消息，这是吞吐量最高的方式，但是可能消息都丢失了，你也不知道的，但是说实话，你如果真是那种实时数据流分析的业务和场景，就是仅仅分析一些数据报表，丢几条数据影响不大的。会让你的发送吞吐量会提升很多，你发送弄一个batch出，不需要等待人家leader写成功，直接就可以发送下一个batch了，吞吐量很大的，哪怕是偶尔丢一点点数据，实时报表，折线图，饼图。2）acks=all，或者acks=-1：这个leader写入成功以后，必须等待其他ISR中的副本都写入成功，才可以返回响应说这条消息写入成功了，此时你会收到一个回调通知3）acks=1：只要leader写入成功，就认为消息成功了，默认给这个其实就比较合适的，还是可能会导致数据丢失的，如果刚写入leader，leader就挂了，此时数据必然丢了，其他的follower没收到数据副本，变成leader

如果要想保证数据不丢失，得如下设置：

a)min.insync.replicas = 2，ISR里必须有2个副本，一个leader和一个follower，最最起码的一个，不能只有一个leader存活，连一个follower都没有了b)acks = -1，每次写成功一定是leader和follower都成功才可以算做成功，leader挂了，follower上是一定有这条数据，不会丢失c) retries = Integer.MAX_VALUE，无限重试，如果上述两个条件不满足，写入一直失败，就会无限次重试，保证说数据必须成功的发送给两个副本，如果做不到，就不停的重试，除非是面向金融级的场景，面向企业大客户，或者是广告计费，跟钱的计算相关的场景下，才会通过严格配置保证数据绝对不丢

5 重试乱序

消息重试是可能导致消息的乱序的，因为可能排在你后面的消息都发送出去了，你现在收到回调失败了才在重试，此时消息就会乱序，所以可以使用“max.in.flight.requests.per.connection”参数设置为1，这样可以保证producer同一时间只能发送一条消息