Kafka性能调优分析-线上环境篇

我就是我 2023-03-14 05:28 9阅读 0赞

![format_png][]

点击上方“蓝字”关注我们

![format_png 1][]

![format_png 2][]

###     ###

##  ##

一、背景介绍：

在平时的开发中，使用kafka来发送数据已经非常熟悉，但是在使用的过程中，其实并没有比较深入的探索kafka使用过程中

一些参数配置，带来的损失可能就是没有充分的发挥出kfka的优势，无法很好的满足业务场景。在意识这个问题后，专门腾出

时间来总结一下kakfa参数配置的调优，以充分发挥kafka在低时延，高吞吐等不同场景下的优势。

###     ###

##  ##

二、通用介绍：

###     ###

**-------- 生产者配置 -------**

常规参数设置解析：

Properties props = new Properties();
    props.put("bootstrap.servers", "localhost:9092"); 
    props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
    props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
    props.put("buffer.memory", 67108864); 
    props.put("batch.size", 131072); 
    props.put("linger.ms", 100); 
    props.put("max.request.size", 10485760); 
    props.put("acks", "1"); 
    props.put("retries", 10); 
    props.put("retry.backoff.ms", 500);
    
    KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);

**1、内存缓冲的大小：buffer.memory**

![format_png 3][]

首先我们看看“buffer.memory”这个参数是什么意思？

**Kafka的客户端发送数据到服务器，一般都是要经过缓冲的**，也就是说，你通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲

里，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的。所以这个“buffer.memory”的本质就是用来约束KafkaProducer能够使用的内存缓

冲的大小的，他的默认值是32MB。那么既然了解了这个含义，大家想一下，在生产项目里，这个参数应该怎么来设置呢？你可以先想一下，如果这个内

存缓冲设置的过小的话，可能会导致一个什么问题？首先要明确一点，那就是在内存缓冲里大量的消息会缓冲在里面，形成一个一个的Batch，每个Batch

里包含多条消息。然后KafkaProducer有一个Sender线程会把多个Batch打包成一个Request发送到Kafka服务器上去。

![format_png 4][]

那么如果要是内存设置的太小：

可能**导致一个问题**：消息快速的写入内存缓冲里面，但是Sender线程来不及把Request发送到Kafka服务器。这样是不是会造成内存缓冲很快就被写满？一旦被写满，

就会阻塞用户线程，不让继续往Kafka写消息了。所以对于“buffer.memory”这个参数应该结合自己的实际情况来进行压测，你需要测算一下在生产环境，你的用户线程会

以每秒多少消息的频率来写入内存缓冲。比如说每秒300条消息，那么你就需要压测一下，假设内存缓冲就32MB，每秒写300条消息到内存缓冲，是否会经常把内存缓冲

写满？经过这样的压测，你可以调试出来一个合理的内存大小。

** 2、多少数据打包为一个Batch合适：batch.size**

接着你需要思考第二个问题，就是你的“batch.size”应该如何设置？

这个东西是决定了你的**每个Batch要存放多少数据就可以发送出去了**。比如说你要是给一个Batch设置成是16KB的大小，那么里面凑够16KB的数据就可以发送了。这个参数的

默认值是16KB，一般可以尝试把这个参数调节大一些，然后利用自己的生产环境发消息的负载来测试一下。

比如说发送消息的频率就是每秒300条，那么如果比如“batch.size”调节到了32KB，或者64KB，是否可以提升发送消息的整体吞吐量。因为理论上来说，提升batch的大小，可以允许

更多的数据缓冲在里面，那么一次Request发送出去的数据量就更多了，这样吞吐量可能会有所提升。但是这个东西也不能无限的大，过于大了之后，要是数据老是缓冲在Batch里迟

迟不发送出去，那么岂不是你发送消息的延迟就会很高。比如说，一条消息进入了Batch，但是要等待5秒钟Batch才凑满了64KB，才能发送出去。那这条消息的延迟就是5秒钟。所以

需要在这里按照生产环境的发消息的速率，调节不同的Batch大小自己测试一下最终出去的吞吐量以及消息的 延迟，设置一个最合理的参数。

**3、要是一个Batch迟迟无法凑满怎么办：linger.ms**

要是一个Batch迟迟无法凑满，此时就需要引入另外一个参数了，“linger.ms”，他的含义就是说一个Batch被创建之后，最多过多久，不管这个Batch有没有写满，都必须发送出去了。

给大家举个例子，比如说batch.size是16kb，但是现在某个低峰时间段，发送消息很慢。这就导致可能Batch被创建之后，陆陆续续有消息进来，但是迟迟无法凑够16KB，难道此时就一直等着吗？

当然不是，假设你现在设置“linger.ms”是50ms，那么只要这个Batch从创建开始到现在已经过了50ms了，哪怕他还没满16KB，也要发送他出去了。所以“linger.ms”决定了你的消息一旦写入一个Batch，

最多等待这么多时间，他一定会跟着Batch一起发送出去。避免一个Batch迟迟凑不满，导致消息一直积压在内存里发送不出去的情况。**这是一个很关键的参数。**这个参数一般要非常慎重的来设置，

要配合batch.size一起来设置。举个例子，首先假设你的Batch是32KB，那么你得估算一下，正常情况下，一般多久会凑够一个Batch，比如正常来说可能20ms就会凑够一个Batch。

那么你的linger.ms就可以设置为25ms，也就是说，正常来说，大部分的Batch在20ms内都会凑满，但是你的linger.ms可以保证，哪怕遇到低峰时期，20ms凑不满一个Batch，还是会在25ms之后强制Batch发送出去。

如果要是你把linger.ms设置的太小了，比如说默认就是0ms，或者你设置个5ms，那可能导致你的Batch虽然设置了32KB，但是经常是还没凑够32KB的数据，5ms之后就直接强制Batch发送出去，这样也不太好其实，会导致你的Batch形同虚设，一直凑不满数据。

**4、最大请求大小 ：“max.request.size”**

这个参数决定了每次发送给Kafka服务器请求的最大大小，同时也会限制你一条消息的最大大小也不能超过这个参数设置的值，这个其实可以根据你自己的消息的大小来灵活的调整。给大家举个例子，你们公司发送的消息都是那种大的报文消息，每条消息都是很多的数据，一条消息可能都要20KB。此时你的batch.size是不是就需要调节大一些？比如设置个512KB？然后你的buffer.memory是不是要给的大一些？比如设置个128MB？只有这样，才能让你在大消息的场景下，还能使用Batch打包多条消息的机制。但是此时“max.request.size”是不是也得同步增加？

因为可能你的一个请求是很大的，默认他是1MB，你是不是可以适当调大一些，比如调节到5MB？

**5、重试机制：“retries”和“retries.backoff.ms”**

“retries”和“retries.backoff.ms”决定了重试机制，也就是如果一个请求失败了可以重试几次，每次重试的间隔是多少毫秒。

这个大家适当设置几次重试的机会，给一定的重试间隔即可，比如给100ms的重试间隔。

**6、确认机制：acks**

此配置是表明当一次produce请求被认为完成时的确认值。特别是，多少个其他brokers必须已经提交了数据到他们的log并且向他们的leader确认了这些信息。典型的值包括： 0：表示producer从来不等待来自broker的确认信息（和0.7一样的行为）。这个选择提供了最小的时延但同时风险最大（因为当server宕机时，数据将会丢失）。1：表示获得leader replica已经接收了数据的确认信息。这个选择时延较小同时确保了server确认接收成功。-1：producer会获得所有同步replicas都收到数据的确认。同时时延最大，然而，这种方式并没有完全消除丢失消息的风险，因为同步replicas的数量可能是1。如果你想确保某些replicas接收到数据，那么你应该在topic-level设置中选项min.insync.replicas设置一下。

** 7、min.insync.replicas：**

当生产者设置应答为"all"(或“-1”)时，此配置指定了成功写入的副本应答的最小数。如果没满足此最小数，则生产者将引发异常(NotEnoughReplicas或NotEnoughReplicasAfterAppend) 当min.insync.replicas和acks强制更大的耐用性时。典型的情况是创建一个副本为3的topic，将min.insync.replicas设置为2，并设置acks为“all”。如果多数副本没有收到写入，这将确保生产者引发异常。

###     ###

##  ##

消费者配置

###     ###

** 1、fetch.min.bytes:**

每次fetch请求时，server应该返回的最小字节数。如果没有足够的数据返回，请求会等待，直到足够的数据才会返回。

**2、auto.commit.enable**

如果为真，consumer所fetch的消息的offset将会自动的同步到zookeeper。这项提交的offset将在进程挂掉时，由新的consumer使用。

###     ###

##  ##

三、优化进阶篇：**优化之 --- 提升吞吐量**

###     ###

![format_png 5][]

##  ##

优化之 --- 保证低时延

![format_png 6][]

##  ##

优化之 --- 保证高持久

![format_png 7][]

##     ##

##  ##

replica复制配置

##     ##

每个follow从leader拉取消息进行同步数据，follow同步性能由这几个参数决定：

*  num.replica.fetchers：拉取线程数
 *  replica.fetch.min.bytes：拉取最小字节数
 *  replica.fetch.min.bytes：拉取最大字节数
 *  replica.fetch.wait.max.ms：最大等待时间

###     ###

##  ##

优化建议

###     ###

*  num.replica.fetchers 配置多可以提高follower的I/O并发度，单位时间内leader持有更多请求，相应负载会增大，需要根据机器硬件资源做权衡
 *  replica.fetch.min.bytes=1 默认配置为1字节，否则读取消息不及时
 *  replica.fetch.max.bytes= 5 \* 1024 \* 1024 默认为1MB，这个值太小，5MB为宜，根据业务情况调整
 *  replica.fetch.wait.max.ms follow拉取频率，频率过高，会导致cpu飙升，因为leader无数据同步，leader会积压大量无效请求情况

### 压缩速度 ###

*  compression.type：压缩的速度上lz4=snappy<gzip。

### 有序性 ###

*  max.in.flight.requests.per.connection (affects ordering，设置为1可以保证有序性，但是发送性能会受影响。不为1的时候，如果发生消息重发则会乱序),在单个连接中，producer客户端在阻塞之前，可以允许未被确认的最大请求数，即当一个连接中未被确认的请求数超过了该设置，那么该producer客户端将会阻塞。注意：如果该值设置得比1大，当出现发送失败的情况，且`retries`配置项又开启时，那么存在消息被重新排序的风险。

### 幂等性：enable.idempotence ###

重要性：低 类型：Boolean 默认值：false

是否使用幂等性。如果设置为true，表示producer将确保每一条消息都**恰好**有一份备份；如果设置为false，则表示producer因发送数据到broker失败重试使，可能往数据流中写入多分重试的消息。

注意：如果使用idempotence，即`enable.idempotence`为true，那么要求配置项`max.in.flight.requests.per.connection`的值必须小于或等于5；配置项`retries`的值必须大于0；`acks`配置项必须设置为*all*。如果这些值没有被用户明确地设置，那么系统将自动选择合适的值。如果设置的值不合适，那么会抛出`ConfigException`异常。

![format_png 8][]

●[5个常用的大数据可视化分析工具][5]

[如何做架构设计说明书][Link 1]

●[架构设计说明书该怎么写？][Link 2]

●[漫谈从零访问量到每秒千万访问量的架构设计][Link 3]

●[腾讯计费金融级技术架构演进][Link 4]

![format_png 9][]

![format_png 10][]

[format_png]: /images/20230312/39fea12960bf4eeb8c0816f2ad462aec.png
[format_png 1]: /images/20230312/17fced30377449c292ef264ca5139ff8.png
[format_png 2]: /images/20230312/8d259a08533d41e68ee27c5d2a6866c8.png
[format_png 3]: /images/20230312/cfd0368ea0d848b6adf3b520373a2609.png
[format_png 4]: /images/20230312/59502c486fa844fe95af10bc98c7dfc5.png
[format_png 5]: /images/20230312/60aa1caf0f1d48508e4d2f04db7f1638.png
[format_png 6]: /images/20230312/579872cffdec4db4ae5c28bdf9c0f7ee.png
[format_png 7]: /images/20230312/38f18df8de514aed87c7144ddcdc493d.png
[format_png 8]: /images/20230312/540ac46408f3438abdd6b1a4a6a6bf29.png
[5]: https://blog.csdn.net/u012811805/article/details/106089143
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44f1a1cb3378b76989f4bfac5a527789c248f2ca66042ec0b074ade65e87327364349b90b6&idx=1&mid=2247484568&scene=21&sn=902102644deeb34dc1d1aaeedf429ac2#wechat_redirect
[Link 2]: https://blog.csdn.net/u012811805/article/details/106066744
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44f147cb33785123bff5c6f6f650b38c38bcee1dfeb6a1d4e18b5851b471aec22ac710523d&idx=1&mid=2247484542&scene=21&sn=b9ab61170044c570f6518679c230f66d#wechat_redirect
[Link 4]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44f606cb337f1065fca5622ec8c08735bdddbb5146bd74bb4803b43b8434e3504e91959b6e&idx=1&mid=2247484223&scene=21&sn=3b5732287f86f2567aba846925cb86a3#wechat_redirect
[format_png 9]: /images/20230312/4c8bdd87107b4ca2bee1ba4ade29c25a.png
[format_png 10]: /images/20230312/ceef3d7f755c4b7892a1337bd42d574e.png