kafka单条消息过大导致线上OOM
1 线上问题
kafka生产者罢工，停止生产，生产者内存急剧升高，导致程序几次重启。
查看日志，发现Produce程序爆异常kafka.common.MessageSizeTooLargeException。
查看kafka配置，默认单条消息最大1M，当单条消息长度超过1M，就会出现发送到broker失败，
从而导致消息在producer的队列一直累积，直到Produce OOM。
2 修改步骤
修改kafka的broker配置：message.max.bytes（默认1000000B），单条消息最大长度。使用
kafka时，应预估单条消息的最大长度，不然会发送失败
修改kafka的broker配置：replica.fetch.max.bytes (默认1MB)，broker可复制的消息的最大字
节数。应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去，
从而造成数据丢失
修改消费者程序端配置：fetch.message.max.bytes (默认1MB) – 消费者能读取的最大消息。
应该≥message.max.bytes。若不调节该参数，会导致消费者无法消费到消息，且不会爆出异
常或警告，导致消息在broker累积，按需调整上三参数
3 是否参数调节得越大越好或者说，单条消息越大越好？
（1）性能
通过性能测试，kafka在消息为10K时吞吐量达到最大，更大消息降低吞吐量，在设计集群的
容量时，尤其要考虑。
（2）可用的内存和分区数
Brokers会为每个分区分配replica.fetch.max.bytes参数指定的内存空间，假设
replica.fetch.max.bytes=1M
且有1000个分区，则需近1G内存，确保分区数最大的消息不会超过服务器内存，否则OOM。
消费端的fetch.message.max.bytes指定最大消息需要的内存空间，同样，分区数最大需要内
存空间不能超过服务器内存。如果有大消息要传送，则在内存一定时，只能使用较少分区数
或使用更大内存的服务器
（3）GC
更大的消息会让GC更长（因为broker需分配更大的块），关注GC日志和服务器日志信息。
若长时间的GC导致kafka丢失了zk的会话，则需配置zookeeper.session.timeout.ms参数
为更大的超时时间
