1. 程式人生 > 其它 >Kafka訊息格式的轉變及不同版本的相容性

Kafka訊息格式的轉變及不同版本的相容性

Kafka訊息格式的轉變 https://blog.csdn.net/u013256816/article/details/80300225

簡單來說分為三個版本:

v0:Kafka 0.10.0版本之前

v1:從0.10.0版本開始到0.11.0版本之前

 

 v1版本比v0版的訊息多了個timestamp的欄位

v2:從0.11.0版本開始

這個版本的訊息相比於v0和v1的版本而言改動很大,同時還參考了Protocol Buffer而引入了變長整型(Varints)和ZigZag編碼。

 

 生產環境上的kafka-clients版本為0.10.2.1,服務端版本為2.12-2.8.0,發現可以正常生產消費,不受影響。 

Kafka雙向相容

在Kafka 0.10.2.0之前,Kafka伺服器端和客戶端版本之間的相容性是“單向”的,即高版本的broker可以處理低版本client的請求。反過來,低版本的broker不能處理高版本client的請求。由於升級client要遠比升級broker簡單得多,因此這個限制給很多使用者帶來了麻煩,甚至有很多人都不願意去升級broker版本——畢竟無downtime的情況下正確升級Kafka伺服器是個不小的挑戰。自0.10.2.0版本開始,社群對這個問題進行了優化,0.10.2.0之後使用者可以簡單地升級client端程式碼到這個版本就可以很容易地實現與低版本Kafka伺服器的互動了。

最近遇到了 kafka server 和 kafka-client 的相容性問題。研發環境用的 kafka 叢集是 2.0.0,而程式使用的 kafka-client 版本是 0.10.1.1,發現生產訊息報錯。將 kafka 叢集的訊息格式修改成了 0.10.2 後,問題解決。遂記錄下 kafka 版本相容的問題。

考慮到Java版本的client已經被廣大使用者直接使用了,社群也改寫了Java clients底層的網路客戶端程式碼,裡面會自動地判斷連線的broker端所支援client請求的最高版本,並自動建立合乎標準的請求。因此,對於FETCH請求和PRODUCE請求而言, 使用者不用擔心需要自己實現這些細節。

類別

作用

.index  偏移量索引檔案

.log  日誌檔案

.snapshot  日誌快照

.timeindex   時間戳索引檔案

leader-epoch-checkpoint  用於副本同步的檢查點檔案