Kafka 0.10的消息格式有新的变化，加入了timestamp字段。磁盘存储的消息格式可以通过server.properties的log.message.format.version配置，默认值是0.10.0.0。
如果一个consumer的版本低于0.10，那么它只能解析0.10以前的数据格式。在这种情况下，Kafka broker会为这个低版本consumer将数据转换到它能够解析的低版本格式。但同时broker将不能使用zero-copy传输，因为数据必须读到application cache中进行数据格式转换。为了避免这种转换开销，我们可以在broker升级到0.10之后，将数据声明为更低版本的格式，比如0.9.0.1。这样，当老版本的consumer尝试获取数据时，broker能够使用zero-copy直接将数据传输给consumer。当大多数consumer都升级到最新版本之后，我们可以将消息格式重新声明称0.10（默认值）。而对于已经升级到0.10的client来说则不受影响。
另外有一些需要注意的是：
在设置log.message.format.version时，必须保证所有的存量数据必须是不高于设置的消息格式。否则低版本的consumer会中断。尤其需要注意在消息格式在设置为0.10之后，不能再设置回低于0.10的版本。
由于timestamp字段被加入消息中，消息本身的开销会增加，因此producer的吞吐量会降低。如果消息本身的size很小，那么新字段对于开销的增加会很明显，吞吐量会明显降低；而相对来说如果消息的size比较大，性能影响就不那么大。同样的，消息的replication也同样会增加8个字节的开销。如果Kafka已经快要把网络压榨到极限，那么这个改动可能会成为最后一根稻草，你可能会遇到一些报错和性能问题。
如果已经在producer中使用了压缩机制，那么你可能会感觉到性能相比之前有所降低，又或者是数据压缩率降低。在0.10中，当broker收到压缩的消息时，它会避免再将消息压缩，一般来说这可以降低延迟和提高吞吐量。但在特定情况下，这可能反而会降低producer的batch size，从而使吞吐量进一步降低。如果碰到这种情况，可以调整producer的linger.ms和batch.size。
