Kafka如何在分布式環境中工作

這篇文章主要介紹“Kafka如何在分布式環境中工作”，在日常操作中，相信很多人在Kafka如何在分布式環境中工作問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kafka如何在分布式環境中工作”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

什么是消息系統?

在了解Kafka之前，如果您不知道什么是Message Queue，則需要添加它。 如果您已經知道，則可以跳到下一段。

> Morden Distributed System

如上圖所述，Message Queue是一個在兩個系統之間傳輸和存儲消息的中間件。 其外觀具有以下優點：

• 去耦：只要您確保雙方遵守相同的接口約束，就可以獨立擴展或修改雙方的處理。

• 冗余：消息隊列將數據保留到完成處理為止，從而避免了數據丟失的風險。  在許多消息隊列采用的"插入-獲取-刪除"范式中，從隊列中刪除消息之前，您的處理系統需要清楚地表明該消息已被處理，以確保您的數據安全保存。 完成使用它。

• 可伸縮性：由于消息隊列使您的處理脫鉤，因此，只要添加其他處理，就很容易增加消息入隊和處理的頻率。

• 靈活性和高峰處理能力：在流量急劇增加的情況下，應用程序仍然需要繼續發揮作用，但是這種突發流量并不是標準的。  毫無疑問，以能夠處理高峰訪問為標準來投資資源是巨大的浪費。 消息隊列的使用可使關鍵組件承受突然的訪問壓力，而不會由于意外的過載請求而完全崩潰。

• 可恢復性：當系統的某些部分發生故障時，它不會影響整個系統。  消息隊列減少了進程之間的耦合，因此，即使處理消息的進程掛斷了，恢復系統后仍可以處理添加到隊列中的消息。

• 順序保證：在大多數使用情況下，數據處理的順序至關重要。 大多數消息隊列最初都是經過排序的，可以保證數據將按特定順序進行處理。  (Kafka保證分區中消息的順序)

• 緩沖：有助于控制和優化通過系統的數據流速度，并解決生產消息和消耗消息的不一致處理速度。

• 異步通信：很多時候，用戶不希望也不需要立即處理消息。 消息隊列提供了一種異步處理機制，該機制允許用戶將消息放入隊列，但不能快速處理。  將所需數量的消息放入隊列，然后在需要時進行處理。

同時，我認為最大的缺點是復雜性，其優點完全可以忽略不計。

Kafka如何運作?

對于Kafka而言，從獨立的角度來看，其中包括生產者，消費者和經紀人。

• 生產者負責將消息發送到代理固定主題

• 代理維護一組主題并管理該主題中的分區

• 消費者，負責從經紀人的相應主題中提取消息

> Kafka components

如圖所示，不同的生產者可以將消息發送到多個主題的多個分區，而消費者也可以從各種主題中消費。

生產者和消費者完全孤立。

在此設計中，它充分體現了去耦，靈活性和峰值處理能力，訂單保證和異步通信。

Kafka如何在分布式環境中工作?

1. 集群

多個代理和副本。

• 副本，分區副本，以確保分區的高可用性

• 領導者，副本，生產者和使用者中的角色僅與領導者互動

• 追隨者中的一個角色，副本以復制領導者中的數據。

Kafka如何保證冗余，可恢復性和高可用性?

即使某些節點發生故障，復制也可以提供高可用性：

• 生產者可以繼續發布消息

• 使用者可以繼續接收消息。 有兩種方案可確保強而一致的數據復制：主備份復制和基于仲裁的復制。 兩種方案都需要選舉一位領導者，其他人則作為跟隨者。  所有寫操作都發送給領導者，然后領導者將消息發送給跟隨者。

基于仲裁的復制可以使用筏和Paxos等算法，例如Zookeeper，Google Spanner等。在2n  +1個節點的情況下，最多可以容忍n個節點故障。

僅在成功接收到消息后，基于主數據庫的復制以及其他主數據庫和備份的寫入操作才能成功。  對于n個節點，最多可以容忍n-1個節點故障，例如Microsoft的PacifiaA。

這兩種方法各有優缺點。

• 基于仲裁的延遲可能比主備份更好，因為基于仲裁的方法僅需要一些節點即可成功寫入以返回。

• 在相同數量的節點下，基于主備份的復制可以承受更多的節點故障，并且只要一個節點處于活動狀態就可以正常工作。

• 在有兩個節點的情況下，主備份可以提供容錯能力，基于仲裁的方法至少需要三個節點。

Kafka采用第二種方法，即主從模式，該方法主要基于容錯能力，并且在兩個節點的情況下也可以提供高可用性。

如果節點很慢怎么辦?

首先，這種情況很少發生。 如果發生這種情況，您可以設置超時參數來處理這種情況。

Kafka的復制適用于分區。

例如，在上圖中，有四個代理，一個主題和兩個分區。 復制因子是三。  當生產者發送消息時，它將選擇一個分區，例如topic1-part1分區，將消息發送到該分區的領導者，broker2，broker3將拉出消息，消息被拉出后，從屬將發送ack到  主機，這次主機僅提交此日志。

在此過程中，生產者有兩種選擇：

• 一種是等待所有副本被成功提取，然后生產者盤收到成功的響應。

• 另一種是等待領導者成功編寫并獲得成功的響應。

在第一個中，您可以確保在異常情況下不會丟失消息，但是延遲會減少。  后者的等待時間已大大改善，但是一旦出現異常情況，從屬服務器將無法在領導掛起之前提取最新消息。 在這種情況下，可能會丟失該消息。

2. 客戶群

消費者使用消費者組名稱標記自己，并且發布到主題的每條記錄都會傳遞到每個訂閱消費者組中的一個消費者實例。  使用者實例可以在單獨的進程中或在單獨的機器上。

如果所有使用者實例都具有相同的使用者組，那么將在這些使用者實例上有效地平衡記錄。

如果所有使用者實例具有不同的使用者組，則每條記錄將廣播到所有使用者進程形成正式文件

簡而言之，消費者群體是Kafka生態系統中的真正消費者。

3. 控制者

上圖是2015年Kafka Controller的設計圖。 Controller和ZK共同構建了Kafka的高層架構，該架構主要完成以下任務：

• 管理經紀人和消費者的動態加入和離開。

• 觸發負載平衡。 當經紀人或使用者加入或離開時，將觸發負載均衡算法，從而為一個使用者組中的多個使用者進行訂閱負載均衡。

• 維護每個分區的消耗關系和消耗信息。

為什么Kafka這么快?

Kafka中有一個過程，其中大量網絡數據被持久保存到磁盤(生產者到代理)，并且磁盤文件通過網絡發送(經紀人到消費者)。

此過程的性能直接影響Kafka的整體吞吐量。

1. 零復制

上圖的左側是傳統的四個副本和四個上下文切換。

• 首先，通過系統調用將文件數據讀入內核狀態緩沖區(DMA復制)

• 然后，應用程序將內存狀態緩沖區數據讀入用戶狀態緩沖區(CPU副本)

• 接下來，用戶程序在通過套接字發送數據時讀取用戶狀態緩沖區數據。復制到內核狀態緩沖區(CPU復制)

• 最后，通過DMA復制將數據復制到NIC緩沖區。 同時，它伴隨著四個上下文切換。

在上圖的右側，Kafka使用Linux 2.4+內核sendfile系統調用來實現零復制。

• 數據通過DMA復制到內核狀態緩沖區

• 它通過DMA直接復制到NIC緩沖區，而無需CPU復制

因為sendfile調用完成了整個文件讀取網絡的傳輸，所以整個過程只有兩個上下文切換，因此性能大大提高了。

準確地說，Kafka的數據傳輸是通過TransportLayer完成的，其子類PlaintextTransportLayer通過Java  NIO的FileChannel的transferTo和transferFrom方法實現了零復制。

2. 順序訪問

> Compare

上圖顯示，即使順序讀取磁盤，順序訪問的巨大優勢也比基于內存的隨機訪問要好。

Kafka中的每條消息都會被追加，并且不會從中間寫入或刪除消息，以確保順序訪問磁盤。

即使是順序讀取和寫入，過多的小型IO操作也會導致磁盤瓶頸，并且這次變成了隨機讀取和寫入。

Kafka的策略是匯總消息并分批發送，以最大程度地減少對磁盤的訪問。 因此，Kafka的主題和分區的數量不應過多。

通常，經過64個主題/分區之后，Kafka的性能將急劇下降。

3. 段日志

• Kafka使用該主題來管理消息。 每個主題包含多個部分，每個部分對應一個邏輯日志，并且由多個部分組成。

• 多個消息存儲在每個段中。 它的邏輯位置決定了消息ID，即消息ID可以直接定位到消息的存儲位置，從而避免了ID到位置的附加映射。

• 每個部分對應于內存中的一個索引，并記錄每個段中第一條消息的偏移量。

• 發布者發送給特定主題的消息將平均分配到多個部分(隨機或根據用戶指定的回調函數)，代理接收已發布的消息并將消息添加到相應部分的最后一段。  當段上的消息數達到配置的值或消息發布時間超過閾值時，段上的消息將刷新到磁盤，只有刷新到磁盤的消息訂閱者才能訂閱該消息。  段達到特定大小后，將不再有數據寫入該段，代理將創建一個新段。

這種分區分割和索引設計不僅提高了數據讀取的效率，而且還提高了數據操作的并行性。

4. 高性能Broker

Kafka在Broker中的設計也是其如此之快的原因之一。

首先，客戶端發送的所有請求都將發送到接受器。 代理中將默認有三個線程。 這三個線程稱為處理器。

接受者將不會對客戶的請求進行任何處理，而是直接對其進行封裝。 將socketChannel發送到這些處理器以形成隊列。

發送的方法是輪詢，即先發送到第一個處理器，然后再發送到第二個，第三個處理器，然后再返回到第一個處理器。  當使用者線程使用這些socketChannel時，它將獲取請求請求，并且數據將伴隨這些請求請求。

默認情況下，線程池中有八個線程。 這些線程用于處理請求和解析請求。 如果請求是書面請求，則將其寫入磁盤。 如果讀取，則返回結果。  處理器將從響應中讀取響應數據，然后將其返回給客戶端。

這是Kafka的三層網絡架構。

因此，如果我們需要增強和調整Kafka，增加處理器并增加線程池中的處理線程，則可以達到效果。  考慮到處理器生成請求的速度過快，并且線程數量不足以及時處理請求，因此請求和響應實際上是一種緩存效果。

到此，關于“Kafka如何在分布式環境中工作”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！