到目前爲止，我們討論了Kafka的核心概念。 讓我們現在來看一下Kafka的工作流程。
Kafka只是分爲一個或多個分區的主題的集合。Kafka分區是消息的線性有序序列，其中每個消息由它們的索引(稱爲偏移)來標識。Kafka集羣中的所有數據都是不相連的分區聯合。 傳入消息寫在分區的末尾，消息由消費者順序讀取。 通過將消息複製到不同的代理提供持久性。
Kafka以快速，可靠，持久，容錯和零停機的方式提供基於pub-sub和隊列的消息系統。 在這兩種情況下，生產者只需將消息發送到主題，消費者可以根據自己的需要選擇任何一種類型的消息傳遞系統。 讓我們按照下一節中的步驟來了解消費者如何選擇他們選擇的消息系統。
發佈 - 訂閱消息的工作流程
以下是Pub-Sub消息的逐步工作流程 -
生產者定期向主題發送消息。
Kafka代理存儲爲該特定主題配置的分區中的所有消息。 它確保消息在分區之間平等共享。 如果生產者發送兩個消息並且有兩個分區，Kafka將在第一分區中存儲一個消息，在第二分區中存儲第二消息。
消費者訂閱特定主題。
一旦消費者訂閱主題，Kafka將向消費者提供主題的當前偏移，並且還將偏移保存在Zookeeper系綜中。
消費者將定期請求Kafka(如100 Ms)新消息。
一旦Kafka收到來自生產者的消息，它將這些消息轉發給消費者。
消費者將收到消息並進行處理。
一旦消息被處理，消費者將向Kafka代理髮送確認。
一旦Kafka收到確認，它將偏移更改爲新值，並在Zookeeper中更新它。 由於偏移在Zookeeper中維護，消費者可以正確地讀取下一封郵件，即使在服務器暴力期間。
以上流程將重複，直到消費者停止請求。
消費者可以隨時回退/跳到所需的主題偏移量，並閱讀所有後續消息。
隊列消息/用戶組的工作流
在隊列消息傳遞系統而不是單個消費者中，具有相同組ID
的一組消費者將訂閱主題。 簡單來說，訂閱具有相同 Group ID
的主題的消費者被認爲是單個組，並且消息在它們之間共享。 讓我們檢查這個系統的實際工作流程。
生產者以固定間隔向某個主題發送消息。
Kafka存儲在爲該特定主題配置的分區中的所有消息，類似於前面的方案。
單個消費者訂閱特定主題，假設
Topic-01
爲Group ID
爲Group-1
。Kafka以與發佈 - 訂閱消息相同的方式與消費者交互，直到新消費者以相同的
組ID
訂閱相同主題Topic-01
1 。一旦新消費者到達，Kafka將其操作切換到共享模式，並在兩個消費者之間共享數據。 此共享將繼續，直到用戶數達到爲該特定主題配置的分區數。
一旦消費者的數量超過分區的數量，新消費者將不會接收任何進一步的消息，直到現有消費者取消訂閱任何一個消費者。 出現這種情況是因爲Kafka中的每個消費者將被分配至少一個分區，並且一旦所有分區被分配給現有消費者，新消費者將必須等待。
此功能也稱爲
使用者組
。 同樣，Kafka將以非常簡單和高效的方式提供兩個系統中最好的。
ZooKeeper的作用
Apache Kafka的一個關鍵依賴是Apache Zookeeper，它是一個分佈式配置和同步服務。Zookeeper是Kafka代理和消費者之間的協調接口。Kafka服務器通過Zookeeper集羣共享信息。Kafka在Zookeeper中存儲基本元數據，例如關於主題，代理，消費者偏移(隊列讀取器)等的信息。
由於所有關鍵信息存儲在Zookeeper中，並且它通常在其整體上覆制此數據，因此Kafka代理/ Zookeeper的故障不會影響Kafka集羣的狀態。Kafka將恢復狀態，一旦Zookeeper重新啓動。 這爲Kafka帶來了零停機時間。Kafka代理之間的領導者選舉也通過使用Zookeeper在領導者失敗的情況下完成。