行業最受歡迎的流媒體平臺概述
介紹
Kafka是當今行業中的新流行語。 幾乎所有領先的科技公司都在其平臺上使用Kafka。 但是問題是它是什麼，為什麼要這麼大肆宣傳？
Kafka是一個分佈式，水平可擴展的流媒體平臺。 它是一個開源流處理平臺。 Kafka起源於LinkedIn，後來在2011年成為開源Apache項目，然後在2012年成為一流的Apache項目。Kafka用Scala和Java編寫。 它旨在提供一個高吞吐量，低延遲的平臺來處理實時數據饋送。
卡夫卡如何運作
Kafka基於發佈/訂閱模型。 它類似於任何消息傳遞系統。 應用程序（生產者）將消息（記錄）發送到Kafka節點（經紀人），並且所述消息由稱為消費者的其他應用程序處理。 消息存儲在主題中，使用者可以訂閱該主題並收聽這些消息。 消息可以是任何內容，例如傳感器測量值，儀表讀數，用戶操作等。
Kafka Producer and Consumer Model
可以將主題視為存儲/發佈消息的類別/源名稱。
Partition
Kafka主題的大小可能很大，因此可能無法將一個主題的所有數據存儲在單個節點中，因此需要將數據劃分為多個分區。 分區允許我們通過跨多個代理（Kafka節點）拆分特定主題中的數據來並行化主題，即每個分區可以放置在單獨的機器上，以允許多個使用者並行地從主題中讀取內容。 主題分區可以基於任何事物，例如它們的進入順序，哈希，id等。
為了提高分區的可用性，每個分區還具有副本。 為了更好地理解它，我們有一個由3個節點/代理組成的Kafka集群。
現在，一個主題分為3個分區，每個代理都有每個分區的副本。 在這些分區副本中，一個人當選為領導者，而其他人只是被動地使自己與Leader保持同步。
There are 3 partitions of a topic named as Partition 0, Partition 1 and Partition 2
對主題的所有寫入和讀取都將通過相應的分區領導程序，並且領導程序協調使用新數據更新副本。 如果領導者失敗，則副本將接任新的領導者。
Write is only through leader and replicas get updated asynchronously.
為了使生產者/消費者從分區中進行寫入/讀取，他們需要知道其領導者，對嗎？ 這些信息需要在某個地方可用。Kafka將此類元數據存儲在名為Zookeeper的服務中。
日誌解剖
Kafka性能和可伸縮性的關鍵是日誌。 初聽此"日誌"時，開發人員常常會感到困惑，因為我們習慣於根據應用程序日誌來理解"日誌"。 但是，我們在這裡談論的是日誌數據結構。 日誌是一種持久的有序數據結構，僅支持追加。 您不能修改或刪除記錄。 從左到右讀取它，並保證項目排序。
Log structure
數據源將消息寫入日誌，並且一個或多個使用者在他們選擇的時間點從日誌中讀取消息。
此日誌中的每個條目都由offset唯一標識，offset只是一個順序索引號，就像數組一樣。
由於此序列/偏移只能維護在特定的節點/代理上，而不能維護在整個集群中，因此Kafka僅保證按分區劃分數據順序。 如果您的用例需要完整的數據排序，則可以相應地定義分區鍵。
卡夫卡中的數據持久性
Kafka實際上將所有消息存儲在磁盤中，而不是存儲在RAM中，並且在日誌結構中對消息進行排序使它能夠利用順序的磁盤讀寫操作。
這是一個常見的選擇，如何將它存儲在硬盤上是一個很好的選擇，並且它仍然具有良好的性能，這背後有很多原因
· Kafka具有將消息分組在一起的協議。 這允許網絡請求將消息分組在一起並減少網絡開銷，服務器又將消息塊一次性保留下來，並且消費者可以一次獲取大型線性塊，從而減少了磁盤操作
· Kafka嚴重依賴OS頁面緩存進行數據存儲，即有效地使用機器上的可用RAM。
· Kafka以標準化的二進制格式存儲消息，在整個流程中（生產者->經紀人->消費者）不加修改，它可以利用零拷貝優化。 就是在操作系統將數據從頁面緩存直接複製到套接字時，有效地完全繞開了Kafka代理應用程序。
· 磁盤上的線性讀/寫速度很快。 現代磁盤速度慢的概念是由於存在大量磁盤搜尋。 Kafka進行線性讀寫，從而使其表現出色。
消費者和消費者群體
使用者可以從任何單個分區讀取數據，從而使您能夠以類似於消息產生的方式擴展消息消耗的吞吐量。 消費者也可以組織成一個給定主題的消費者組-組中的每個消費者都從一個唯一的分區讀取，以避免兩個進程兩次讀取同一條消息，並且整個組消耗了整個主題的所有消息。 如果您有使用者>分區，則某些使用者將處於空閒狀態，因為他們沒有要讀取的分區。 如果您具有分區>使用者，那麼使用者將接收來自多個分區的消息。 如果您有使用者=分區，則每個使用者從一個分區中按順序讀取消息。
可以通過Kafka文檔中的圖像進一步詳細說明
服務器1擁有分區0和3，服務器2擁有分區1和2。我們有兩個使用者組A和B。A由兩個使用者組成，而B由四個使用者組成。 消費者組A有兩個消費者，因此每個消費者都從兩個分區讀取。 另一方面，消費者組B具有與分區相同數量的消費者，因此每個消費者都只能從一個分區讀取數據。
卡夫卡遵循愚蠢的經紀人和聰明的消費者的原則。 這意味著Kafka不會跟蹤消費者讀取了哪些記錄，因此沒有意識到消費者的行為，而是將消息保留了一段可配置的時間，這取決於消費者相應地調整其行為。 消費者自己向Kafka輪詢新消息，並說出他們想閱讀的記錄。 這樣一來，他們便可以根據需要增加/減少偏移量，從而在發生事故時能夠重播和重新處理事件。
例如，如果將Kafka配置為保留一天的消息，而使用者關閉的時間超過一天，則該使用者將丟失消息。 但是，如果使用者休息了一個小時，它可以從其最後一個已知偏移量開始再次讀取消息。
Zookeeper的角色
Zookeeper是一個分佈式鍵值存儲。 對其進行了高度優化，但寫入速度較慢。 Kafka使用Zookeeper進行Kafka Broker和Topic Partition的領導選舉。 Zookeeper也非常容錯，應該如此，因為Kafka嚴重依賴它。
它用於存儲各種元數據，其中包括：
· 消費者組每個分區的偏移量（儘管現代客戶將偏移量存儲在單獨的Kafka主題中）
· ACL（訪問控制列表）—用於限制訪問/授權
· 生產者和消費者配額-最大消息/秒邊界
· 分區負責人及其健康
生產者和消費者不直接與Zookeeper交互以瞭解分區的領導者和其他元數據，而是向Kafka Broker提出元數據請求，而Kafka Broker與Zookeeper交互並給出元數據響應，然後生產者和消費者就知道哪個 他們需要分別讀寫表格的分區。
結論
有充分的理由，Kafka迅速成為任何組織數據管道的骨幹。 通過Kafka，您可以使大量消息通過集中式媒體進行存儲，而不必擔心性能或數據丟失。
Kafka可以成為事件驅動架構的核心，並允許您真正將應用程序彼此分離。
深入閱讀的進一步閱讀
· Kafka文檔-Kafka的詳盡指南
· Kafka Streams變得簡單— Kafka stream API的簡要介紹
· Kafka Connect —要進一步瞭解Kafka Connect API
感謝您抽出時間來閱讀。
(本文翻譯自Nimesh Khandelwal的文章《Understanding Kafka — A Distributed Streaming Platform》，參考：https://medium.com/swlh/understanding-kafka-a-distributed-streaming-platform-9a0360b99de8)
閱讀更多 聞數起舞 的文章
