Apache Kafka 的兒童讀物/插圖指南

點選標題

黑客新聞討論

這是對軟體開發社群的精彩貢獻，本著《Why's Poignant Guide》和《Land of Lisp》的精神。我完全支援這種藝術性、奇思妙想和技術的結合——忠於核心黑客精神。

我和 Kafka 一起工作了十年，發現這絕對是一種享受。

Kafta 找到完美的用例：對於需要對隨時間變化的資料採取動作的任何情況，我都推薦 Kafka - 幾乎任何軟體系統。在幾乎每個系統中，您都希望能夠可靠地記錄事件，並且希望能夠以確定性的方式部分重放您的狀態（例如，在您修復錯誤之後）；這兩件事都應該是一個嚴肅的資料儲存的賭注，但 AFAIK Kafka 實際上是唯一提供它們的人。

Kafka 本身只能解決一半的問題，因為它不提供內建索引，因此您必須自己構建索引狀態，或者甚至可以使用“傳統”資料儲存作為事實上的快取。

Kafta 找到完美的用例：當您有許多伺服器都需要檢視相同的按時間順序排列的資料流（包括它們在網路停機期間可能錯過的訊息）並實時檢視新事件時。

如果在 kafka 配置中設定“log.retention.hours = -1”和“log.retention.bytes = -1”，kafka 將永遠儲存訊息。

例如，在遊戲中，使用者輸入和其他事件可以在 Kafka 中產生，然後通過從頭到尾讀取和處理 kafka 流來重建整個遊戲狀態。它比大多數資料庫有優勢，因為它是實時的。

您還可以使用按時間順序排列的資料流來表示比簡單陣列更復雜的資料結構。例如，可以在保留年表的同時表示一棵樹。然而，這遠非理想的用例。

Akka 和許多 actor 模型服務破壞了微服務的可用性、永續性和一般可靠性，因為攻擊Akka一個隨機節點會造成其混亂，該節點上任何 actor 都可能停止，直到它被轉移。

就像 SOA 和 ESB 一樣，概念不是問題，而是當時設計的技術限制。解耦和訊息傳遞還不錯，但在物理硬體上擁有傳統訊息佇列並不能真正站得住腳。任何派生架構都面臨同樣的問題。

再說一次，Kafka 不是 actor 模型實現，Akka 也不是分割槽冗餘流處理系統，它們沒有那麼多重疊；-)