链接：https://pan.baidu.com/s/1CFgBFY5WvAQ9s13odvfT_Q 

提取码：pj1n 

 

1、如何提升生产者的吞吐量？

1）buffer.memory:设置发送消息的缓存区大小，默认值是32M。如果发送消息出去的速度小于写入消息进去的速度，那么此时生产消息就会阻塞住，所以这里就应该多做一些压力测试，尽可能的保证这块缓冲区不会被写满导致生产消息被阻塞住。

2）compression.type,默认值是none,不压缩，但是也可以用lz4压缩，效率还不错，压缩之后可以减小数据量，提升吞吐量，但是会加大producer端的cpu开销。

3）batch.size，设置batch的大小，如果batch太小，会导致频繁的网络请求，吞吐量下降，如果batch太大的话，会导致一条消息需要等待很久才能发送出去，而且会让内存缓冲区有很大的压力，过多的数据缓冲在内存中，默认值是16K，也就是说一个batch满了16K就会发送出去，一般在实际情况中，这个batch的值可以调大一些，以提升吞吐量；

4）linger.ms 这个默认值是0，意思是消息必须立即发送出去，但这是不对的，一般设置100ms左右，也就是说，这个消息被发送出去，进入一个batch,如果是100ms以内，满了16K的话，自然会被发送出去，但到了100ms,然而batch还没满16K的话，那么也必须把消息发送出去，不能让消息的发送延迟时间太长，也避免给内存造成过大的压力；

2、如何保证kafka内部数据不丢失？

从三个角度来回答：producer,consumer,broker

1)producer

acks参数 1/0/-1

acks=0

生产者发送消息之后，不需要等待服务器响应，他不管消息有没有成功发送出去，如果发送过程中遇到了异常，导致broker端没有接收到消息，消息也就丢失了，实际上，他只是把消息发送到了socketBuffer（缓存）中，而socketBuffer为什么没有被提交到broker他并不关心，他不能保证broker端是否接收到了消息，但是这样的配置对retry不起作用，因为producer端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没写数据。这么不保险的操作为什么还会有这样的操作呢？kafka对于收集海量数据，如果在收集某一项日志时是允许数据量有一定的丢失的话，就可以用这样的配置来收集日志。

acks=1(默认值)

生产者发送消息后，只要分区的leader partition成功写入消息，那么他就会收到来自服务端的成功响应，其实就是消息只发给了leader partition，leader partition收到消息后会返回ack到producer端，如果消息无法写入leader partition(选举，宕机等情况发生时)，生产都会收到一个错误的响应，为了避免丢失数据，producer可以选择重发消息，如果消息成功写入，在被其他副本同步数据时，此时恰好leader宕机，副本无法同步到数据，此时剩下的副本会选举出新的leader partition，但两个副本都没有刚刚写入的这条数据，导致数据丢失；acks设置为1是消息可靠性和吞吐拉斯能够折中的方案。

acks=-1(或all)

生产者在发送消息之后，需要等待ISR中的所有副本都成功写入消息之后才能够收到来自服务器的响应，在配置环境相同的情况下，此种配置可以达到最强的可靠性，需要follower都同步完数据，也就是ISR队列中的所有broker全部保存完消息才会向ack发送消息，表示发送成功。

retry参数：

在kafka中，错误分为两种，一种是可恢复的，另一种是不可恢复的。

可恢复性的错误：

如果遇到在leader选举、网络抖动等这些异常时，如果我们这个时候配置的retries大于0，也就是可以进行充实操作，那么等到leader选举完，网络稳定后，这些异常就会消失，错误也可以恢复，数据再次重发时就会正常发送到broker端，需要注意retries之间的时间间隔，以确保在充实时可恢复性错误都已经恢复。

不可恢复性错误：

如：超过了发送消息的最大值(max.request.size)时，这种错误是不可恢复的，如果不做处理，那么数据将会丢失 ，因此我们需要注意在发生异常时把这些消息写入到DB、缓存到本地文件中等等，把这些不成功的数据记录下来，等错误修复后，再把这些数据发送到broker端。

配置方案：

 1.高可用型：

配置:acks=all,retries >0 retry.backoff.ms=100(根据实际情况设置retry可能恢复的时间间隔)

优点：这样保证了producer端每发送一条消息都要成功，如果不成功将消息缓存起来，等异常恢复后再次发送。

缺点：这样保证了高可用，但是会导致集群的吞吐量不是很高，因为数据发送到leader之后，leader要将数据同步到follower，如果网络贷款不稳定，ack的响应时长会长。

2.折中型：

配置:acks=1 retyies>0 设置retries时间间隔

优点：保证了消息的可靠性和吞吐量，是个折中的方案

缺点：性能介于两者之间

3.高吞吐量型：

配置：acks=0 

优点：可以相对的容忍一些数据的丢失，吞吐量大，可以接收大量请求

缺点：不知道发送的消息是否成功

2）Consumer

group.id:

consumer group分组的一个id,消费者隶属的消费组的名称，在kafka中只允许消息只能被某个消费组中的一个消费者消费，如果为空，则会报异常，对于一个新的consumer加入到消费时，肯定会属于某个消费组，只有这样才能消费数据。

auto.offset.reset = earliest(最早)/latest（最晚）

从何处开始进行消费  当一个新加入的consumer要进行消费数据，如果这个这个consumer是做数据分析工作的，是需要以前的历史数据，那就从最早的位置消费数据，如果仅仅是查看消费情况，那可以从最晚位置开始消费数据。

enable.auto.commit =true/false（默认是true）

是否开启自动提交偏移量的功能，默认是开启。当设置为true时，意味着由kafka的consumer端自己间隔一定时间会自动提交offset，如果设置成了false，也就是有客户端(自己写代码)来提交，那就还得控制提交的时间间隔。