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

背景故事

今天我們來聊聊 Consumer 三個用來調整 offset的方式，seek, seekToBeginning, and seekToEnd。雖然說大部分時候我們用 Consumer 就是一路順順的讀取下去，但是但是有時我們也會想要調整 offset 的位置，例如改成從頭開始、跳到最後一筆、甚至是從某個特定的位置開始讀取，因此上面三種特別的 seek 方法就是幫助大家愉快且輕鬆的調整資料的位置。不過魔鬼藏在細節裡面，這三個方法看起來要做的事情差不多，但其實實作的內容相當的不一樣。

seek 這個方法使用者可以傳入指定的 offset，因此在實作時我們可以在完完全全尊重使用者的決定下，把使用者指定的 offset 丟出去，然後再根據伺服器的回應來做後續的處理，如果使用者亂指定一通，那我們就依照參數設定的 reset 策略來執行，有可能是自動把 offset 移動到目前最早的資料、也可能是移動到最後一筆、或者是直接丟出錯誤

seekToBeginning和seekToEnd就不太一樣了，在這個狀態下使用者只是告訴我們要去最早/晚的資料，所以如何查出最早/最晚資料的位置就變成我們的責任，因此就需要走多一些路先來驗證一下，首先我們會將目前的 offset 狀態改成等待驗證，然後再後續拉取資料時就會針對尚未驗證的部分送出請求，拜託伺服器端告訴我們現在最早/最晚的資料位置在哪裡，接著根據伺服器端的回應來重置接下來要讀取的資料 offset

一些背景故事收到心裡後，我們馬上來看看今天的議題，也就是新的 AsyncKafkaConsumer 要如何實作seekToBeginning和seekToEnd，或者說現在的實作有什麼問題呢？故事就回到狀態的修改到底該由 application thread or background thread 來修改呢？如果心理看到這個話題感到很困惑的話，建議可以閱讀 https://ithelp.ithome.com.tw/articles/10352334 補充一下知識，所以答案自然就是盡量讓 background thread 來完成狀態的修改，因此瞭解這些內容後故事就非常簡單了，現在 AsyncKafkaConsumer#seekToBeginning 和 AsyncKafkaConsumer#seekToEnd 居然還是由 application thread來修改狀態，真是大逆不道！

解決辦法

老樣子，既然知道問題是什麼，答案就很清楚了。我們應該要重新包裝一個新的事件，把要更改的意圖傳遞給 background thread ，然後application thread就是可以開心的回報使用者，你的操作已經在背景跑了喔，期待下次poll更新喔

附錄

AsyncKafkaConsumer 作為嶄新的下一代 Kafka Consumer，Kafka 社群非常努力的要讓他可以符合大家的期待，同時也盡量符合既有 Consumer的行為，因此如果大家使用上有任何問題，都歡迎回報給社群

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