【异常】转载 kafka.common.MessageSizeTooLargeException

kafka单条消息过大导致生产者程序发送到broker失败：kafka.common.MessageSizeTooLargeException

今天碰到一个问题，kafka生产者罢工停止生产了，而且生产者的内存急剧升高，导致程序几次重启。查看日志，才发现生产者程序爆出异常kafka.common.MessageSizeTooLargeException。

查看kafka broke配置，默认单条消息最大为1M，当单条消息长度超过1M时，就会出现发送到broker失败，从而导致消息在producer的队列中一直累积，直到撑爆生产者的内存。

于是赶紧修改kafka配置，解决问题。主要修改步骤如下：

1.修改kafka的broker配置：`message.max.bytes（默认:1000000B）`，这个参数表示单条消息的最大长度。在使用kafka的时候，应该预估单条消息的最大长度，不然导致发送失败。

2.修改kafka的broker配置：`replica.fetch.max.bytes (默认: 1MB)`，broker可复制的消息的最大字节数。这个值应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去，从而造成数据丢失。

3.修改消费者程序端配置：`fetch.message.max.bytes (默认 1MB)` – 消费者能读取的最大消息。这个值应该大于或等于message.max.bytes。如果不调节这个参数，就会导致消费者无法消费到消息，并且不会爆出异常或者警告，导致消息在broker中累积，此处要注意。

根据需要，调整上述三个参数的大小。但是否参数调节得越大越好，或者说单条消息越大越好呢？参考http://www.mamicode.com/info-detail-453907.html的说法：

1.从性能上考虑：通过性能测试，kafka在消息为10K时吞吐量达到最大，更大的消息会降低吞吐量，在设计集群的容量时，尤其要考虑这点。

2.可用的内存和分区数：Brokers会为每个分区分配replica.fetch.max.bytes参数指定的内存空间，假设replica.fetch.max.bytes=1M，且有1000个分区，则需要差不多1G的内存，确保 分区数*最大的消息不会超过服务器的内存，否则会报OOM错误。同样地，消费端的fetch.message.max.bytes指定了最大消息需要的内存空间，同样，分区数*最大需要内存空间 不能超过服务器的内存。所以，如果你有大的消息要传送，则在内存一定的情况下，只能使用较少的分区数或者使用更大内存的服务器。

3.垃圾回收：更大的消息会让GC的时间更长（因为broker需要分配更大的块），随时关注GC的日志和服务器的日志信息。如果长时间的GC导致kafka丢失了zookeeper的会话，则需要配置zookeeper.session.timeout.ms参数为更大的超时时间。

 

参考：https://blog.csdn.net/hanjibing1990/article/details/51673540