本篇内容介绍了“Kafka消息体大小设置的一些方法”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

成都创新互联公司专业为企业提供大邑县网站建设、大邑县做网站、大邑县网站设计、大邑县网站制作等企业网站建设、网页设计与制作、大邑县企业网站模板建站服务，十年大邑县做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。

还记得前几天有个小伙伴跟我反馈发送消息时提示请求数据过大的异常吗？经过调整 max.request.size 的大小之后，又报了了如下异常

查看相关资料后，发现 Broker 端对 Producer 发送过来的消息也有一定的大小限制，这个参数叫 message.max.bytes，这个参数决定了 Broker 能够接收到的最大消息的大小，它的默认值为 977 KB，而 max.request.size 的值已经设置成 2M 大小了，很显然已经比 message.max.bytes 大了很多，因此消息大于 997KB 时，就会抛出如上异常。

值得一提的是，主题配置也有一个参数，叫 max.message.bytes，它只针对某个主题生效，可动态配置，可覆盖全局的 message.max.bytes，好处就是可以针对不同主题去设置 Broker 接收消息的大小，而且不用重启 Broker。

这还没完，消费端拉取消息数据的大小也需要更改，这个参数叫 fetch.max.bytes，这个参数决定消费者单次从 Broker 获取消息的最大字节数，那么问题来了，如果该参数值比 max.request.size 小，那么会导致消费者很可能消费不了比 fetch.max.bytes 大的消息。

所以综合起来，需要这么设置：

producer端：
max.request.size=5242880（5M）
broker：
message.max.bytes=6291456（6M）
consumer：
fetch.max.bytes=7340032（7M）

max.request.size < message.max.bytes < fetch.max.bytes

另外补充一点，还记得之前说过的 batch.size 参数的作用吗，从源码可看出，Producer 每次发送的消息封装成 ProducerRecord，然后利用消息累加器 RecordAccumulator 添加到 ProducerBatch 中，由于每次创建 ProducerBatch 都需要分配一个 batch.size 大小的内存空间，频繁创建和关闭会导致性能极大开销，所以 RecordAccumulator 内部有个 BufferPool，它实现了缓存的复用，只不过只针对 batch.size 大小的 BufferByte 进行复用，如果大于 batch.size 的 ProducerBatch，它并不会加入 BufferPool 中，也就不会复用。

之前有个疑问就是：假如 max.request.size 大于 batch.size，那么该条消息会不会分多个 batch 发送到 broker？

答案显然是不会，根据上述所说，如果一个 ProducerRecord 就已经超出了 batch.size 的大小，那么 ProducerBatch 仅包含一个 ProducerRecord，并且该 ProducerBatch 并不会加入到 BufferPool 中。

所以，在 Kafka Producer 调优过程中，根据业务需求，需要特别注意 batch.size 与 max.request.size 之间的大小值的设定，避免内存空间频繁地创建和关闭。

“Kafka消息体大小设置的一些方法”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！

网站名称：Kafka消息体大小设置的一些方法
标题路径：http://azwzsj.com/article/gsspgd.html