https://issues.apache.org/jira/browse/KAFKA-17459

故事背景

Kafka為了降低使用者對分散式系統的恐懼，因此以可不下線的思維作為核心理念，當有節點死亡，沒問題，Kafka會自動重新選擇新的節點，並且包裝錯誤透過重試來繼續完成請求。今天資料分佈不夠均衡，沒問題，你隨時可以動態調整資料配置，任何的請求都不會中斷。而這也是這隻系統測試要驗證的項目，當有資料重新分配的請求發生時，此時正在運行的讀寫操作都不應該發生任何錯誤，同時那些被搬動位置的partition在就位之後，也要立刻可以繼續讀寫資料，這樣才是真正的無縫接軌

等等，reassign_partitions_test.py是怎麼確保上述兩個要求？這個故事很簡單，首先該系統測試會檢查讀寫兩端的log檔案，如果有遇到任何的錯誤紀錄，那麼該系統測試就會標記成失敗，這個很直覺。但是第二個要求呢？要如何確保被搬動的partition一樣可以繼續接收資料？這個就稍微麻煩一點，系統測試會去掃描VerifiableProducer的資料輸出，並從中找到partition的資訊，然後只有在每個partition都至少被寫一次資料後，寫入測試的部分才算是完成

乍聽之下，這個好像也很有道理，但是，很不幸的如今第二個要求就是讓reassign_partitions_test.py不穩定的元兇，也就是在寫入測試的過程中無法觀察到所有partition都有被寫入資料，原因是什麼？難不成是有些被移動的partition從此一去不回嘛？當然不是，如果是的話問題就很嚴重了！其實根本原因就是系統預設的partitioner在處理資料分配的邏輯在3.3.0後有了天翻地覆的變化 ...

這個變化看來複雜但說來簡單，過往的預設partitioner會盡量平均的把資料分散在partitions之間，然而在現今這個Kafka使用情境下，人多有白癡叢集大有爛節點，資料如果不幸的被放在爛節點上，就可能因為效能不佳造成資料累積，然後滾雪球般的給爛節點致命一撃，事實上如果爛節點就被打趴搞不好還是好事，最怕的是爛節點打死不下線，繼續提供很慘的吞吐量，最後就是誰的資料被爛節點服務就誰倒霉，哪天被拉正喝咖啡都有可能。所以新的BuiltInPartitioner就將節點的回應時間作爲參考依據，盡量不要把資料放到慢的要死的節點身上，如此就可以盡量避免上述的慘案發生。

講到這裏，是不是有人虎軀一震，想說這樣的話相同key的資料是不是就會被放到不同partition身上？我家應用很在意的資料順序該怎麼辦？Kafka不是只有保證同一個partition內的讀寫資料順序一致嘛？沒錯，如果你心裡有想到這個問題，就代表你是一個聰明且成熟的Kafka使用者，Kafka當然也知道順序的一致性對於使用者而言是多麼的重要，因此只有發生在key不存在或是使用者明確指定partitioner.ignore.keys=true的時候，也就是不需要保證基於key的順序一致時才會採取新的最佳化策略。

解決辦法

看到這裏想必大家都心知肚明解法了，既然reassign_partitions_test.py的目標是確認partition被移動後依然可以讀取資料，那自然就不用去考慮什麼延遲最佳化的鬼問題，因此一個簡單的解法就是讓VerifiableProducer在產生資料時都帶有key，如此預設的BuiltInPartitioner就不會採取延遲最佳化的策略，進而讓資料盡可能的分配到所有的partitions身上

廣告
歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術