升級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：數據存儲量和消費佔用帶寬都明顯減少！

從上圖可以看出，在生產數據相當的情況下，在broker升級前1GB的log文件保存了12分鐘的數據。而在升級後，1GB的log文件保存了接近32分鐘的數據。對這個partition而言，存儲效率是升級前的2.7倍！

不同的partition提升程度並不相同。整體的提升效果，可以從消費數據量看出。

單機：

整個集羣：

升級前後的消費數據量相差4倍！

之前部分服務器的監控數據有日誌刷新延遲超過100ms的警告，升級後也基本消失。

可見，升級Kafka至1.1.0版本對Kafka集羣的磁盤容量、磁盤IO及網絡帶寬資源的佔用都有了明顯的減輕。

分析

由於升級前後：

• producer沒有升級
• 網卡流入流量沒有變化
• 每秒消費消息數沒有變化

可以看出存儲效率的提升是在broker產生的。而broker cpu使用率沒有變化，說明沒有發生額外的消息格式的轉換。

應該是跟官方文檔有提到的下面這個改動有關（我們使用的是snappy壓縮）：