LinkedIn - Apache Kafka 的伸縮擴展能力

如果數據是高科技的生命線的話，Apache Kafka 就是 LinkedIn 公司正在使用中的循環系統。我們使用 Kafka 在多系統之間搬移各類數據，它幾乎每一天都接觸每一個服務器。這個架構的復雜性，以及架構實踐中采用的各種取舍，衍生出一種快速又可靠地大塊數據傳輸的需 求。

什么是 Kafka？

Apache Kafka 是一個演進的發布/訂閱消息系統。系統結合隊列和消息機制，可把它當成在一群服務器間進行的日志提交過程。消息被分成多個主題和分段，每個主題支持多個發 布者（生產者）和多個訂閱者（消費者）。Kafka 群以良好的形式為每一個主題保存著這些消息。

• 對于特定的時間（LinkedIn 在數天內測量）

• 對于分成段的特定大小的消息

• 基于鍵的消息，僅存儲最近的消息

Kafka 提供可靠性、靈活性和盈余保留，同時高吞吐量地處理數據。

已有多篇關于 Kafka 的文章和討論，包括 talk given at ApacheCon 2014 by Clark Haskins 和我自己的。如果你還不熟悉Kafka，你可能需要去查看這些鏈接來學習一些Kafka的基本操作原理。

多大算大？

Kafka 是不關心消息中的內容的。許多不同類型的數據可以在一樣的集群上被簡單的共存，每一種的數據會被分類成不同的主題。生產者和消費者僅僅需要關心他們感興趣 的內容。LinkedIn讓這更進一步，并且定義了四種類別的消息：隊列，度量，日志和追蹤數據，每一類都運行在他們自己的集群上。

當聯合時，在 LinkedIn 的 Kafka 的系統上，每天有超過 8000 億條消息被發送，相當于超過 175 兆兆字節（terabytes）數據，另外，每天還會消耗掉 650 兆兆字節（terabytes）數據的消息，為什么Kafka有這樣的能力去處理這么多產生的數據和消耗掉的數據，對每一種消息分類是一個重要原因。在每 天系統最繁忙的時候，我們每秒接收超過 1300 萬條消息，相當于每秒 2.75 GB 數據。去處理這所有的信息，LinkedIn 運行超過 60 個集群，并在上面部署超過 1100 個 Kafka 代理。

隊列

隊列 是大多數人所想的那種標準信息類型：一個應用的部分生成消息，另一部分消費消息。其它應用對這些消息不感興趣，因為他們是用于協調動作或是單個系統的狀態的。這種類型的消息用于發送郵件，分發由其他在線應用計算出的數據集，或者與后端組件配合工作。

度量

度量 處理所有由應用操作產生的測量結果。這包括面向應用的所有操作系統和硬件的統計數據，只要這些數據能夠確保系統正確運作。這是LinkedIn的耳目，用它能夠看到所有服務器和應用的狀態，從而驅動我們內部的監測預警系統。如果你想要對我們的度量了解更多，可以閱讀 我們的自動度量系統的原始設計， 也可以看Stephen Bisordi最近發表的 自動度量的下一步往哪走。

日志

日志包括應用程序、系統和公共訪問日志。最初,為了方便,度量和日志共存于同一集群。現在由于日志量太大我們會不斷地將日志數據分離出來。日志數據通過應用程序產生到Kafka,然后會被其他系統讀取用以日志聚合。

跟蹤

跟蹤包括了LinkedIn的基礎架構前線中發生的所有行為，不管是的用戶的還是應用程序的。這些行為不僅需要與其他應用程序交互也會進入到 Apache Samza的流處理和Apache Hadoop的批處理中。這正是大數據的立足之處:持續更新搜索索引,跟蹤付費服務的使用以及實時測量大規模增長的趨勢。這四種類型的消息機制對LinkedIn的正常運行至關重要,而跟蹤數據則較為常見,因為執行層比較重視而且通常可以帶來效益。

分層和聚合

與所有大型網站一樣，LinkedIn需要管理大量的數據中心。一些應用，例如那些服務于特定的用戶請求的應用，它們只需要關心在一個數據中心發生了什么。還有許多其它應用，例如那些維持搜索目錄的應用，它們需要檢查所有的數據中心發生了什么。

對于每個消息目錄，LinkedIn具有一個創建在數據中心的名為本地消息容器的集群。它同樣也是一個聚合集群，它將所有的本地集群的消息整合到一個給定的目錄。我們使用Kafka鏡像生成器應用來將本地消息復制聚合，這樣可以避免任何的本地集群之間的消息循環。

  圖 1：Kafka分層架構設計

使用Kafka基礎架構來移動數據可以減少帶寬消耗和網絡延遲，因為它可以讓我們的消息復制次數最小化（每個數據中心一次）。用戶可以在當地使用數據，這 樣就簡化他們的配置并且讓他們不需要再關心多種跨數據中心的網絡問題。生產者和用戶完成了Kafka基礎架構中的分層概念。生產者是第一層，本地集群（結 合所有的數據中心）是第二層，每個聚合集群都是一個額外的層級。用戶本身是最后一層。

這種分層的基礎架構解決了許多問題，但是極大地復雜化了Kafka的監控和確保它的正常運行。因為一個單一的Kafka集群正常運行時，是不會丟失消息 的，當引入了額外的層之后，伴隨著額外的組件加入，例如鏡像生成器，當消息消失的時候會生成無數的故障，另外監視Kafka集群和它們的狀況，我們需要一 個中間層來確保所有生成的消息都出現每一層，并且使它成為這些數據的關鍵用戶。

審計完整性

Kafka Audit 是 LinkedIn 的一個內部工具，這個工具用來確保所有生產的消息無丟失的復制到每一層。消息結構包含一個所有消息共有的包含關鍵數據的頭部，關鍵數據包括時間戳、生產服 務和原始主機。當單個生產者發送消息到Kafka的時候，它會記錄當前時間間隔發送消息的數量。然后它周期性的發送這個數量到特定的審計主題 （topic）。這就提供了每個生產者向某個主題嘗試發送消息量的信息。

我們的 Kafka 基礎設施應用之一，被稱做 Kafka Console Auditor，消費單個 Kafka 集群中所有主題的所有消息。它周期性的發送消息到審計主題，統計上一個時間間隔該集群中每個主題消費的消息量。通過比較這些數量和生產者的數量，我們就可 以判斷是否所有的生產的消息已經進入 Kakfa 系統。如果數量對不上，我們就能知道某個生產者有問題，然后就可以追蹤故障的服務和主機。每個 Kafka 集群有自己的 console auditor，用于驗證集群中的消息。通過互相比較每一層的數量，我們可以保證每一層具有相同數量的消息。這就可以保證既沒有丟失也沒用重復消息，如果 有問題就能直接采取行動。

  

圖 2: Kafka 消息審計概況

某些關鍵的消息消費者，比如Hadoop grids，也做為單獨一層回寫審計信息。這使得我們不僅可以監控生產者是否在工作，Kafka是否在傳遞消息，也可以檢驗消費者是否收到了所有消息。如 果應用將消息從Kafka復制到hadoop出現了問題，那么Kafka審計工具將會顯示一個錯誤，標明Hadoop使用的那一層的名字。這最后一塊功能 給我們提供了端到端的保證，也就是每條生產的數據最終會被消費。

將所有內容組合在一起

簡單的Kafka集群上面的這些層看起來很復雜——這給我們提出一個艱巨的任務，如何使LinkedIn的所有應用以相同的方式工作——但是我們有秘密王 牌。LinkedIn有一個Kafka工程師團隊，其中包括一些頂級的開源Kafka開發者。他們為LinkedIn開發社區提供內部支持，幫助內部團隊 以一致的、可維護的方式使用Kafka。對于任何想要知道如何實現生產者、消費者，或者深入了解Kafka的特定設計問題的人，他們是共同的交流溝通的團 隊。

Kafka 開發團隊也為 LinkedIn 提供了其他好處，也就是在開源 Kafka 庫之上的一系列自定義庫，這些庫可以將額外的功能連接在一起。例如，LinkedIn 內部的幾乎所有 Kafka 消息生產者都使用了一個稱為 TrackerProducer 的庫。當應用調用該庫發送消息的時候，這個庫將會插入消息頭部字段、注冊消息結構，同時跟蹤、發送審計消息。同樣的，消費者庫將會從注冊服務拉取消息結構 信息，反序列化 Avro 消息。大部分 Kafka 基礎設施應用，比如 console auditor，也由該開發團隊維護。

 

圖 3: LinkedIn 內部的 Kafka 即服務

展望

就像 Mammad Zadeh，我們的技術總監， 最近說的， LinkedIn 對于 Kafka 的承諾如故。工程師團隊在 Kafka 開源社區非常活躍。其中的工作包括強安全控制、配額控制，確保 LinkedIn 能夠擴展到每天1萬億條消息，乃至更多。我們基于 Kafka 之上構建的流處理框架，Samza，最近已完成孵化，成為頂級項目。

SRE 團隊正與工程師們一起工作，確保我們資深的運營經驗可以與開發者的代碼經驗保持同步。SRE 團隊也在持續自動化運行 Kafka 的流程，為諸如移動分片（partition）等任務構建工具，這將會集成到 Kafka 的組件中。我們也在持續的評估大規模運行 Kafka 的最佳調優策略，將我們的發現盡可能的告訴社區。

我們在 Apache Kafka 的郵件列表也很活躍，LinkedIn 很榮幸的主持著 Apache Kafka Meetup 和 Bay Area Samza Meetup，交替著每月一次。親自參與會議，或者遠程參加會議，來發現更多關于 LinkedIn 和其他公司使用 Kafka 和 Samza 的信息吧！