本文在綠泡泡“狗哥瑣話”首發於2024.12.23 <-關注不走丟。

上期Fluss的內容還算受歡迎，這期加更，講講Fluss RoadMap裏提到的Zero Disks是怎麼個事兒。

所謂Zero Disks就是把所有的存儲放在S3這種遠程，容量無限的存儲上。這樣集羣本身就可以做到無狀態了。

那這玩意兒會怎麼做呢？我們直接看一篇先成的文章。

原文鏈接：

https://medium.com/thedeephub/how-do-we-run-kafka-100-on-the-...

這個AutoMQ，就是Kafka on S3的實現。

AutoMQ的目標是讓Kafka不犧牲性能的情況下， 將所有消息都寫入對象存儲。從而提高Kafka的效率和彈性。

這裏的不犧牲性能——應該説是“在絕大多數的場景”會比較嚴謹。

那接下來我們先來看一下AutoMQ的寫入流程。

數據寫進來的時候先進緩存（我們可以稱為寫緩存），然後呢，用DirectIO的方式把WAL寫進硬盤（一般用AWS的EBS），這個時候就會告知生產者寫入成功了。在這之後會做一個異步的刷入到S3。

DirectIO：繞過操作系統直接寫文件系統緩存的實現，可以減少延遲並大幅提高性能，但是要寫代碼的人自己關注數據對齊、緩衝區等底層細節。

雖然S3和EBS都在遠程，但是它們的寫入時機是有很大的不同的。EBS作為WAL的存儲，肯定在最短時間內能夠多攢數據就攢進去，然後刷到EBS，這意味着它的先決條件是時間。這個可以理解，因為它刷數據越及時，需要恢復的時間也就越短。

而寫到S3的數據則可以優先攢量，這樣可以增加吞吐量。

接着我們來看一下讀流程。

還是先走緩存，再走S3。但有點不同的是，這裏有個Block Cache，這個緩存是在讀的時候生成的。讀取的時候會順帶一些預讀。

這下我們知道了，AutoMQ裏有兩個緩存：日誌緩存處理寫入和熱讀取（相當於最新數據的緩存），然後用塊緩存進行冷讀取（相當於歷史數據的緩存）。

然後最後要説的是恢復。文章裏寫了個case：

AutoMQ 集羣有兩個broker A 和 B，每個代理都有兩個關聯的 EBS 存儲。當其中一個一個broker掛掉的時候，會發生什麼事情？

• 如前所述，一旦broker確認消息已進入 WAL （EBS），則認為消息已成功收到。
• 那麼，如果brokerA崩潰了怎麼辦？該brokerA的 EBS 存儲設備發生了什麼情況？尚未寫入對象存儲的 EBS 數據如何？
• AutoMQ 利用 AWS EBS 多重掛載功能來處理這種情況。broker A 關閉後，EBS 設備 A 將連接到broker  B。當broker B 有兩個 EBS 卷時，它將知道哪個卷是通過標籤從空閒狀態附加的。broker B 會將 EBS 存儲 A 的數據刷新到 S3，然後刪除該卷。此外，在將孤立 EBS 卷附加到broker  B 時，AutoMQ 會利用 NVME 預留來防止數據意外寫入此卷。這些策略可顯著加快故障轉移過程。
• 新創建的broker將具有新的 EBS 存儲。

這裏面使用到了AWS的一些機制，不過多重掛載一般公有云都是有的，所以AutoMQ也不是依賴於AWS實現的。