接上篇，今天做了个测试，看log.message.format.version对consumer性能的影响到底有多大，一共20万条数据，每条数据大小1K，总共200M。
首先在Kafka 0.9上的平均测试结果是8.362秒。
而升级到Kafka 0.10之后，平均测试结果如下：
| producer version | log.message. format.version | consumer version | cost |
|---|---|---|---|
| 0.9 | 0.10 | 0.9 | 8.966s |
| 0.9 | 0.10 | 0.10 | 6.470s |
| 0.10 | 0.10 | 0.9 | 8.834s |
| 0.10 | 0.10 | 0.10 | 6.604s |
| 0.9 | 0.9 | 0.9 | 8.355s |
| 0.9 | 0.9 | 0.10 | 6.242s |
| 0.10 | 0.9 | 0.9 | 8.233s |
| 0.10 | 0.9 | 0.10 | 6.310s |
- 对比1-5，2-6，3-7，4-8，使用默认的log.message.format.version=0.10.0会使吞吐量降低，因为消息里增加了8个字节timestamp，虽然原始size是1K，只增加了8‰的大小，但从测试结果看，吞吐量降低远远不止8‰ 。
- 设置log.message.format.version=0.9，吞吐量和kafka0.9差不多。这个很好理解。
- producer的版本不影响消费吞吐量。无论produce的message是什么版本，保存到broker之后都以log.message.format.version为准，因此consume的性能是不受影响的。
- 0.10的consumer吞吐量大大优于0.9consumer，
结论：
- 无论如何，kafka broker升级到0.10之后，优先使用0.10 consumer，效率高
- 从性能上考虑，应该设置log.message.format.version=0.9，但这样就不能使用0.10的message的新特性，比如timestamp
