| 失效链接处理 |
|
Kafka常见面试?PDF 下蝲
本站整理下蝲Q?/strong>
链接Q?a target="_blank">https://pan.baidu.com/s/1CFgBFY5WvAQ9s13odvfT_Q
提取码：pj1n
相关截图Q?/strong>
主要内容Q?/strong>
1、如何提升生产者的吞吐量？
1Qbuffer.memory:讄发送消息的~存区大，默认值是32M。如果发送消息出ȝ速度于写入消息q去的速度Q那么此时生产消息就会阻塞住Q所以这里就应该多做一些压力测试，可能的保证q块~冲Z会被写满D生消息被阻塞住?/div>
2Qcompression.type,默认值是none,不压~，但是也可以用lz4压羃Q效率还不错Q压~之后可以减数据量Q提升吞吐量Q但是会加大producer端的cpu开销?/div>
3Qbatch.sizeQ设|batch的大，如果batch太小Q会D频繁的网l请求，吞吐量下降，如果batch太大的话Q会D一条消息需要等待很久才能发送出去，而且会让内存~冲区有很大的压力，q多的数据缓冲在内存中，默认值是16KQ也是说一个batch满了16K׃发送出去，一般在实际情况中，q个batch的值可以调大一些，以提升吞吐量Q?/div>
4Qlinger.ms q个默认值是0Q意思是消息必须立即发送出去，但这是不对的Q一般设|?00ms左右Q也是_q个消息被发送出去，q入一个batch,如果?00ms以内Q满?6K的话Q自然会被发送出去，但到?00ms,然而batchq没?6K的话Q那么也必须把消息发送出去，不能让消息的发送gq时间太长，也避免给内存造成q大的压力；
2、如何保证kafka内部数据不丢失？
从三个角度来回答Qproducer,consumer,broker
1)producer
acks参数 1/0/-1
acks=0
生者发送消息之后，不需要等待服务器响应Q他不管消息有没有成功发送出去，如果发送过E中遇到了异常，Dbroker端没有接收到消息Q消息也׃׃Q实际上Q他只是把消息发送到了socketBufferQ缓存）中，而socketBufferZ么没有被提交到broker他ƈ不关心，他不能保证broker端是否接收到了消息，但是q样的配|对retry不v作用Q因为producer端都不知道是否发生了错误Q而且对于offset的获取永q都?1Q因为broker端可能还没写数据。这么不保险的操作ؓ什么还会有q样的操作呢Qkafka对于攉量数据Q如果在攉某一Ҏ(gu)志时是允许数据量有一定的丢失的话Q就可以用这L配置来收集日志?/div>
acks=1(默认?
生者发送消息后Q只要分区的leader partition成功写入消息Q那么他׃收到来自服务端的成功响应Q其实就是消息只发给了leader partitionQleader partition收到消息后会q回ack到producer端，如果消息无法写入leader partition(选DQ宕机等情况发生?Q生产都会收C个错误的响应Qؓ了避免丢失数据，producer可以选择重发消息Q如果消息成功写入，在被其他副本同步数据Ӟ此时恰好leader宕机Q副本无法同步到数据Q此时剩下的副本会选D出新的leader partitionQ但两个副本都没有刚刚写入的q条数据Q导致数据丢失；acks讄?是消息可靠性和吞吐拉斯能够折中的方案?/div>
acks=-1(或all)
生者在发送消息之后，需要等待ISR中的所有副本都成功写入消息之后才能够收到来自服务器的响应，在配|环境相同的情况下，此种配置可以辑ֈ最强的可靠性，需要follower都同步完数据Q也是ISR队列中的所有broker全部保存完消息才会向ack发送消息，表示发送成功?/div>
retry参数Q?/div>
在kafka中，错误分ؓ两种Q一U是可恢复的Q另一U是不可恢复的?/div>
可恢复性的错误Q?/div>
如果遇到在leader选D、网l抖动等q些异常Ӟ如果我们q个时候配|的retries大于0Q也是可以q行充实操作Q那么等到l(f)eader选D完，|络E_后，q些异常׃消失Q错误也可以恢复Q数据再ơ重发时׃正常发送到broker端，需要注意retries之间的时间间隔，以确保在充实时可恢复性错误都已经恢复?/div>
不可恢复性错误：
如：过了发送消息的最大?max.request.size)Ӟq种错误是不可恢复的Q如果不做处理，那么数据会丢失 Q因此我们需要注意在发生异常时把q些消息写入到DB、缓存到本地文g中等{，把这些不成功的数据记录下来，{错误修复后Q再把这些数据发送到broker端?/div>
配置Ҏ(gu)Q?/div>
1.高可用型Q?/div>
配置:acks=all,retries >0 retry.backoff.ms=100(Ҏ(gu)实际情况讄retry可能恢复的时间间?
优点Q这样保证了producer端每发送一条消息都要成功，如果不成功将消息~存hQ等异常恢复后再ơ发送?/div>
~点Q这样保证了高可用，但是会导致集的吞吐量不是很高，因ؓ数据发送到l(f)eader之后Qleader要将数据同步到followerQ如果网l贷ƾ不E_Qack的响应时长会ѝ?/div>
2.折中型：
配置:acks=1 retyies>0 讄retries旉间隔
优点Q保证了消息的可靠性和吞吐量，是个折中的方?/div>
~点Q性能介于两者之?/div>
3.高吞吐量型：
配置Qacks=0
优点Q可以相对的容忍一些数据的丢失Q吞吐量大，可以接收大量h
~点Q不知道发送的消息是否成功
2QConsumer
group.id:
consumer group分组的一个id,消费者隶属的消费l的名称Q在kafka中只允许消息只能被某个消费组中的一个消费者消费，如果为空Q则会报异常Q对于一个新的consumer加入到消Ҏ(gu)Q肯定会属于某个消费l，只有q样才能消费数据?/div>
auto.offset.reset = earliest(最?/latestQ最晚）
从何处开始进行消?nbsp; 当一个新加入的consumer要进行消Ҏ(gu)据，如果q个q个consumer是做数据分析工作的，是需要以前的历史数据Q那׃最早的位置消费数据Q如果仅仅是查看消费情况Q那可以从最晚位|开始消Ҏ(gu)据?/div>
enable.auto.commit =true/falseQ默认是trueQ?/div>
是否开启自动提交偏U量的功能，默认是开启。当讄为trueӞ意味着由kafka的consumer端自己间隔一定时间会自动提交offsetQ如果设|成了falseQ也是有客L(自己写代?来提交，那就q得控制提交的时间间隔?br />
|
| Java1234官方?5Q?/td> | 
|
| Java1234官方?5Q?/td> | 838462530 |
苏公|安?32061202001004?/p>
