https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=321719077

背景故事

Kafka Consumer作為最重要的客戶端元件，它提供的各種基礎設施協助我們在坡濤洶湧的串流中不斷前行。用來建立分散式客戶端的重要機制consumer group更是陪伴我們度過無數童年，其中兩大派系dynamic member和static member不知道大家對他們是否熟悉呢？沒聽過？沒關係小編我來娓娓道來：

dynamic member適用於大多數的consumer使用情境，如果你沒聽過這樣很好，代表你的應用情境沒有脫離consumer的使用範圍，故事結束 ... 開玩笑的，dynamic member顧名思義就是隨時加入群組幫忙也會隨時中離老子不幹的類型，當一個consumer是使用dynamic member加入群組時，首先consumer需要自己產生或是跟伺服器要一個member id，然後透過這個member id來觸發新一輪的負載平衡並且獲得屬於自己的任務範圍，最後在consumer關閉時送出一個離開的請求給伺服器端，告知自己要離開了，請把我手上的任務分配給其他人，如此確保這個cosumer群體可以繼續消費指定的資料範圍

故事到此一樣很完美吧？可惜人類的本性就是做死，總是要在安穩中找刺激。上述說明中有一個玩意叫做負載平衡，搞過分散式系統的人都知道，這鬼東西長期來看是好的，但短期內對系統一定會有一些影響，例如當你要把某個人的工作轉移到另個人手上時，轉換過程該工作的處理一定會有所影響，如果量體很大時造成的影響就可能跟著擴散。所以試著想想看，如果有一個consumer只是想暫時離開去買個飯，晚點就會回來繼續工作，那麼此時我們要觸發負載平衡嘛？當然不要，否則等他回來時又要再觸發一次，那不是整個團隊被他一個人影響。所以在這個情境下，dynamic member就不是一個適合的解法。

接下來就輪到static member的誕生，相對動態的member，static member就是用來解決暫時離開的行為，我們可以給每一個consumer給定一個唯一的static member id，今天如果你的consumer程式預期會有暫時下線的需求，例如跑更新，那麼在建立consumer的時候就可以指定參數group.instance.id，那麼之後跑更新把consumer下線時，consumer就不會真的離開群組，因此群組也不會觸發負載平衡，等晚一點consumer重新上線用相同的group.instance.id加入群組時，原本他手上的任務就會再交給他繼續處理。

故事到此一樣很完美吧？可惜人類的本性就是做死，總是要在安穩中找刺激。如果group.instance.id啟動的consumer是真的想中離那該怎麼辦？預設行為中伺服器端會在超時後把發呆的consumer通通踢掉，但我們當然不想等到超時，不然這段時間都沒產出可能會被老闆罵死。另一個手段就是透過Admin直接送出請求把對應的consumer踢掉，但這樣做就很麻煩，還要另外開一個Admin來處理。有沒有可能我們能在關閉consumer的時候給一個設定，指定說這次的關閉是永久離開還是暫時離開呢？

解決辦法

既然知道問題，解法自然跟著出現。KIP-1092就是要擴充關閉時的彈性，讓我們可以處理上述問題的情境。然而一個延伸的問題，有沒有什麼情境是dynmaic member是需要暫時離開或是不要離開的呢？如果有那麼我們自然也要讓關閉的彈性擴展到dynamic member，否則我們是否就只需要為了static member做加強？這個問題目前也在社群上討論中，歡迎各位讀者提出你的寶貴想法，謝謝大家的閱讀

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