kafka单条消息过大导致线上OOM，运维连夜跑路了！
1 线上问题
kafka生产者罢工，停止生产，生产者内存急剧升高，导致程序几次重启。
查看日志，发现Pro程序爆异常kafka.common.MessageSizeTooLargeException。
查看kafka配置，默认单条消息最大1M，当单条消息长度超过1M，就会出现发送到broker失败，从而导致消息在producer的队列一直累积，直到Pro OOM。
赶紧修改kafka配置，解决问题。
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 是否参数调节得越大越好
或者说，单条消息越大越好？参考http://www.mamicode.com/info-detail-453907.html说法：
3.1 性能
通过性能测试，kafka在消息为10K时吞吐量达到最大，更大消息降低吞吐量，在设计集群的容量时，尤其要考虑。
3.2 可用的内存和分区数
Brokers会为每个分区分配replica.fetch.max.bytes参数指定的内存空间，假设
replica.fetch.max.bytes=1M
且有1000个分区，则需近1G内存，确保分区数最大的消息不会超过服务器内存，否则OOM。
消费端的fetch.message.max.bytes指定最大消息需要的内存空间，同样，分区数最大需要内存空间不能超过服务器内存。所以，若你有大消息要传送，则在内存一定时，只能：
- 使用较少分区数
- 或使用更大内存的服务器
3.3 GC
更大的消息会让GC更长（因为broker需分配更大的块），关注GC日志和服务器日志信息。若长时间的GC导致kafka丢失了zk的会话，则需配置zookeeper.session.timeout.ms参数为更大的超时时间。