公司日志系统的Kafka集群多年来一直使用0.8.2版本，当前Kafka已经发展到1.x, 2.x，有必要升级到较高的版本，以使用更新的功能。
本次计划升级至比较稳定的1.1.0版本。
升级步骤
参考官方文档：https://kafka.apache.org/documentation/#upgrade_1_1_0
- 每台服务器部署Kafka 1.1.0程序
- 修改配置文件，加上
inter.broker.protocol.version=0.8.2
log.message.format.version=0.8.2 - 逐台关闭0.8.2，启动1.1.0
- 全部升级后，修改配置文件，去掉：
inter.broker.protocol.version=0.8.2 - 逐台重启
- 检查分区及主分区的分布是否均匀，进行调整
Client端因为分布太广暂时没有升级计划，因此broker的log.message.format.version=0.8.2配置需要一直保留，避免broker做格式转换。
升级效果
1. 可以做到zero downtime平滑升级。
2. 升级的side effect：数据存储量和消费占用带宽都明显减少！
kafka_partition_size.png
从上图可以看出，在生产数据相当的情况下，在broker升级前1GB的log文件保存了12分钟的数据。而在升级后，1GB的log文件保存了接近32分钟的数据。对这个partition而言，存储效率是升级前的2.7倍！
不同的partition提升程度并不相同。整体的提升效果，可以从消费数据量看出。
单机：
kafka_broker_outgoing.png
整个集群：
kafka_cluster_outgoing.png
升级前后的消费数据量相差4倍！
之前部分服务器的监控数据有日志刷新延迟超过100ms的警告，升级后也基本消失。
可见，升级Kafka至1.1.0版本对Kafka集群的磁盘容量、磁盘IO及网络带宽资源的占用都有了明显的减轻。
分析
由于升级前后：
- producer没有升级
- 网卡流入流量没有变化
- 每秒消费消息数没有变化
可以看出存储效率的提升是在broker产生的。而broker cpu使用率没有变化，说明没有发生额外的消息格式的转换。
应该是跟官方文档有提到的下面这个改动有关（我们使用的是snappy压缩）：
kafka_notable_change.png
