升级Kafka的side effect

公司日志系统的Kafka集群多年来一直使用0.8.2版本，当前Kafka已经发展到1.x, 2.x，有必要升级到较高的版本，以使用更新的功能。

本次计划升级至比较稳定的1.1.0版本。

升级步骤

参考官方文档：https://kafka.apache.org/documentation/#upgrade_1_1_0

1. 每台服务器部署Kafka 1.1.0程序
2. 修改配置文件，加上
   inter.broker.protocol.version=0.8.2
log.message.format.version=0.8.2
3. 逐台关闭0.8.2，启动1.1.0
4. 全部升级后，修改配置文件，去掉：
   inter.broker.protocol.version=0.8.2
5. 逐台重启
6. 检查分区及主分区的分布是否均匀，进行调整

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