天天看點

如何使用Apache Kafka處理1億使用者的大型應用程式

作者:不秃頭程式員
如何使用Apache Kafka處理1億使用者的大型應用程式

在大資料和高流量應用程式的世界中,同時處理大量使用者是一個巨大的挑戰。許多全球最受歡迎的應用程式,服務超過1億使用者,依賴于強大、可擴充的架構來管理資料和請求的洪流。這些架構中的關鍵參與者是 Apache Kafka,一個分布式事件流平台,以其高吞吐量、可靠性和可擴充性而聞名。在這篇文章中,我們将探讨大型應用程式如何使用 Apache Kafka 處理1億使用者,重點關注其架構和特性,使這成為可能。

Apache Kafka 是管理大量資料的最受歡迎的平台之一,可以處理數百萬使用者。例如,

Kafka 被許多公司使用,包括 LinkedIn、Uber 和 Netflix。

LinkedIn 使用 Kafka 進行消息交換、活動跟蹤和日志名額處理,每天跨越100多個 Kafka 叢集處理7萬億條消息。

Uber 使用 Kafka 交換使用者和司機之間的資料。

Netflix 使用 Kafka 跟蹤超過2.3億訂閱者的活動,包括觀看曆史、電影喜好和不喜歡,以及您觀看的内容。

PhonePe 使用 Apache Kafka 每天管理大約1000億事件。Kafka 被用來建構實時流應用程式和資料管道,這些應用程式和管道處理資料并在系統之間移動資料。Kafka 還作為一個分布式系統運作,可以擴充以處理許多應用程式,并且可以根據需要存儲資料。

使用 Kafka 的一些其他公司包括 Uber、Shopify、Spotify、Udemy、LaunchDarkly、Slack、Robinhood 和 CRED。

Kafka 還用于消息傳遞、名額收集和監控、日志記錄、事件源、送出日志和實時分析。

Kafka 像 pub-sub 消息隊列一樣工作,允許使用者釋出和訂閱消息流。它還處理流處理,動态計算派生資料集和流,而不僅僅是傳遞消息批次。

Kafka 是建構可靠的事件驅動架構(EDAs)的最可靠解決方案之一,這些架構提供可靠的實時銀行服務。EDA 使資料能夠在松散耦合的事件消費者和事件生産者之間異步流動。

為了為 Kafka Streams 确定容量大小,您可以監控作業系統的性能計數器,以确定 CPU 或網絡是否成為瓶頸。如果 CPU 是瓶頸,您可以通過向應用程式添加更多線程來使用更多 CPU。如果網絡是瓶頸,您可以添加另一台機器并在那裡運作 Kafka Streams 應用程式的克隆。Kafka Streams 将自動在所有機器上運作的所有任務之間平衡負載。

如何使用Apache Kafka處理1億使用者的大型應用程式

這裡有一些 Kafka 真實世界用例的例子:

社交媒體分析

  • 一個社交媒體平台使用 Kafka Streams 實時處理推文,進行情感分析,并提供帶有使用者情感、趨勢和參與度名額的儀表闆。

制造業

  • Kafka 被用于實時監控生産線、裝置狀态和庫存水準。這有助于優化生産效率,減少停機時間,并改善供應鍊管理。

網站活動跟蹤

  • 當您通路一個網站并執行諸如登入、搜尋或點選産品等操作時,Kafka 捕獲這些事件。然後 Kafka 将消息流發送到基于事件類型的特定主題。

Apache Kafka 在高容量應用程式中的作用

Apache Kafka 旨在處理大規模的實時資料流。它在高容量應用程式中的主要作用是作為資料流處理的支柱,使得能夠有效處理每秒數百萬條消息。Kafka 的架構允許它無縫地将資料分布在多個伺服器(或代理)上,確定高可用性和容錯能力。

Apache Kafka 的關鍵特性:

  1. 高吞吐量:Kafka 可以每秒處理數百萬條消息,支援高容量資料流,而不會顯著降低性能。
  2. 可擴充性:Kafka 叢集可以在不停機的情況下擴充,以容納更多生産者、消費者和資料,随着使用者基礎的增長。
  3. 持久性和可靠性:Kafka 確定資料不會丢失,将消息存儲在磁盤上,并在叢集中複制資料以實作容錯。
  4. 低延遲:Kafka 優化了低延遲消息傳遞,這對實時應用程式和服務至關重要。
  5. 資料流解耦:生産者和消費者是解耦的,允許獨立擴充和演進處理應用程式。

處理1億使用者的架構概覽

要處理1億使用者,應用程式必須有一個經過深思熟慮的架構,有效利用 Kafka 的特性。以下是這樣一個架構的簡化概覽:

1. 資料攝取層:

資料攝取層是資料從各種來源進入系統的地方。這可以包括使用者互動、應用程式日志、系統名額等。Kafka 在這一層的作用是有效收集和緩沖這些傳入的資料,確定它們準備好由下遊系統處理。

2. 流處理:

一旦資料進入 Kafka,就可以進行流處理。這涉及到資料流的實時分析和處理,可用于多種目的,如實時分析、監控和觸發自動化操作。Kafka Streams 是一個用戶端庫,用于建構應用程式和微服務,其中輸入和輸出資料存儲在 Kafka 主題中,通常在這一層使用。

3. 資料內建:

Kafka 還促進了資料內建,作為不同系統之間資料流動的中心樞紐。這在微服務架構中至關重要,不同的應用程式元件可能需要有效地通信和共享資料。

4. 可擴充存儲:

Kafka 提供了資料流的持久存儲,允許應用程式根據需要保留和重新處理大量資料。這對于需要保留曆史資料以進行分析或符合監管合規的應用程式尤其重要。

5. 事件驅動架構:

Kafka 使事件驅動架構成為可能,生産者釋出事件(消息)而不需要了解消費者的細節。這種解耦使系統具有更大的可擴充性、靈活性和彈性。

在Honeycomb,Apache Kafka 每秒可以處理多少消息?

在 Honeycomb,輕松超過一百萬條消息。

在這一集中,了解 Honeycomb 如何在大規模上使用 Kafka。Liz Fong-Jones(Honeycomb 主要開發倡導者)解釋了 Honeycomb 如何管理基于 Kafka 的遙測攝取管道,并擴充 Kafka 叢集。

那麼 Honeycomb 是什麼?Honeycomb 是一個可觀測性平台,幫助您可視化、分析和改進雲應用程式的品質和性能。他們的資料量在大流行期間增長了10倍,而總擁有成本隻增加了20%。

為了幫助了解基準測試,讓我快速回顧一下 Kafka 是什麼以及它是如何工作的。Kafka 是一個最初在 LinkedIn 建構的分布式消息系統,現在是 Apache 軟體基金會 的一部分,并被多家公司 使用。

一般設定非常簡單。生産者将記錄發送到叢集,叢集保留這些記錄并将它們分發給消費者:

如何使用Apache Kafka處理1億使用者的大型應用程式

Kafka 中的關鍵抽象是主題。生産者将他們的記錄釋出到一個主題,消費者訂閱一個或多個主題。Kafka 主題隻是一個分片的預寫日志。生産者将記錄追加到這些日志中,消費者訂閱變化。每條記錄都是一個鍵/值對。鍵用于将記錄配置設定給日志分區(除非釋出者直接指定分區)。

這裡是一個單一生産者和消費者從兩個分區主題讀寫的簡單例子。

如何使用Apache Kafka處理1億使用者的大型應用程式

這張圖檔展示了一個生産者程序正在為兩個分區追加日志,以及一個消費者正在讀取相同的日志。日志中的每條記錄都有一個關聯的條目編号,我們稱之為偏移量(offset)。消費者用這個偏移量來描述其在每個日志中的位置。

這些分區分布在一組機器上,允許一個主題存儲的資料量超過任何單一機器的容量。

請注意,與大多數消息系統不同,日志始終是持久的。消息在接收時立即寫入檔案系統。讀取消息後不會删除消息,而是根據一些可配置的服務水準協定(比如幾天或一周)保留消息。這允許在資料消費者可能需要重新加載資料的情況下使用。它還使得支援空間高效的釋出-訂閱成為可能,因為無論有多少消費者,都有一個共享的日志;在傳統的消息系統中,通常每個消費者都有一個隊列,是以添加一個消費者就會使你的資料大小翻倍。這使得Kafka非常适合于傳統消息系統之外的用途,比如作為Hadoop等離線資料系統的管道。這些離線系統可能隻在周期性的ETL周期的間隔中加載,或者可能因維護而關閉幾個小時,在此期間,如果需要,Kafka能夠緩沖甚至TB級别的未消費資料。

Kafka還将其日志複制到多個伺服器上以實作容錯。與其他消息系統相比,我們複制實作的一個重要架構方面是,複制不是需要複雜配置的附加功能,隻用于非常特殊的情況。相反,複制被假定為預設設定:我們将未複制的資料視為特殊情況,複制因子恰好為一。

當生産者釋出包含記錄偏移量的消息時,會收到确認回執。釋出到分區的第一條記錄被賦予偏移量0,第二條記錄為1,以此類推,按照不斷遞增的序列。消費者從指定的偏移量位置消費資料,并通過定期送出來儲存他們在日志中的位置:儲存這個偏移量以防消費者執行個體崩潰,另一個執行個體需要從它的位置恢複。

測試設定

對于這些測試,我有六台機器,每台機器的規格如下:

  • 英特爾至強2.5 GHz處理器,六核
  • 六個7200 RPM SATA硬碟
  • 32GB RAM
  • 1Gb以太網

Kafka叢集設定在其中三台機器上。六個硬碟直接挂載,沒有RAID(JBOD風格)。剩下的三台機器我用于Zookeeper和生成負載。

三台機器的叢集并不大,但由于我們隻會測試到複制因子為三,這就是我們所需要的。顯然,我們總是可以添加更多分區并将資料分散到更多機器上,以水準擴充我們的叢集。

這些硬體實際上并不是LinkedIn通常的Kafka硬體。我們的Kafka機器更适合運作Kafka,但與我這次測試的“現成”精神不太一樣。相反,我從我們的Hadoop叢集中借來了這些,這可能是我們所有持久系統中最便宜的裝置。Hadoop的使用模式與Kafka非常相似,是以這樣做是合理的。

好的,不多說,以下是結果!

挑戰與考慮

雖然Kafka提供了處理1億使用者所需的工具和功能,但還有幾個挑戰和考慮必須解決:

•資料分區和分片:正确的資料分區對于在Kafka叢集中平衡負載和實作高吞吐量至關重要。•監控和管理:這種規模的Kafka叢集需要複雜的監控和管理,以確定最佳性能并迅速解決任何出現的問題。•安全性:處理數百萬使用者的敏感資料需要強大的安全措施,包括加密、通路控制和審計。•合規性和資料治理:大規模系統通常必須遵守各種監管要求,需要謹慎的資料治理實踐。

結論

Apache Kafka的架構和功能使其成為需要處理1億或更多使用者的應用程式的絕佳選擇。通過有效管理高容量資料流,確定可靠性和可擴充性,并支援解耦的事件驅動架構,Kafka使應用程式能夠擴充以滿足龐大使用者基礎的需求。然而,在這種規模上利用Kafka也需要仔細的規劃、監控和管理,以解決相關挑戰并確定系統的彈性和性能。

繼續閱讀