標籤：

重磅發布：Kafka迎來1.0.0版本，正式告別四位數版本號

01-26

編輯 | Natalie & Vincent

AI前線出品｜ ID：ai-front

AI 前線導語：「 Kafka 現在正式迎來了 1.0.0 版本」！

Kafka 從首次發布之日起，已經走過了七個年頭。從最開始的大規模消息系統，發展成為功能完善的分散式流式處理平台，用於發布和訂閱、存儲及實時地處理大規模流數據。來自世界各地的數千家公司在使用 Kafka，包括三分之一的 500 強公司。Kafka 以穩健的步伐向前邁進，首先加入了複製功能和無邊界的鍵值數據存儲，接著推出了用於集成外部存儲系統的 Connect API，後又推出了為實時應用和事件驅動應用提供原生流式處理能力的 Streams API，並於今年春季開始支持僅一次處理語義。如此廣泛的應用和完備的功能以及如此悠久的歷史，無一不在說明 Kafka 已經成為一款穩定的企業級產品。而更為激動人心的是，Kafka 現在正式迎來了 1.0.0 版本！

Kafka 1.0.0 發布的主要內容如下：

  • 0.10.0 版本里開始引入的 Streams API 在 1.0.0 版本里繼續演進，改進了 builder API（KIP-120），新增了用於查看運行時活躍任務的 API（KIP-130）和用於聚合分區的 cogroup API（KIP-150）。增強的 print() 和 writeAsText() 方法讓調試變得更容易（KIP-160）。其他更多信息可以參考 Streams 文檔。
  • 改進了 Connect 的度量指標（KIP-196），新增了大量用於健康監測的度量指標（KIP-188），並提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指標（KIP-168）。
  • 支持 Java 9，實現更快的 TLS 和 CRC32C，加快了加密速度，降低了計算開銷。
  • 調整了 SASL 認證模塊的錯誤處理邏輯（KIP-152），原先的認證錯誤信息現在被清晰地記錄到日誌當中。
  • 更好地支持磁碟容錯（KIP-112），更優雅地處理磁碟錯誤，單個 JBOD 上的磁碟錯誤不會導致整個集群崩潰。
  • 0.11.0 版本中引入的冪等性生產者需要將 max.in.flight.requests.per.connection 參數設置為 1，這對吞吐量造成了一定的限制。而在 1.0.0 版本里，這個參數最大可以被設置為 5（KAFKA-5949），極大提升了吞吐量範圍。

關於新版本更多的變化可以查看發布說明：

dist.apache.org/repos/d

下載源代碼：

apache.org/dyn/closer.c

二進位包

Scala 2.11：

apache.org/dyn/closer.c

Scala 2.12：

apache.org/dyn/closer.c

正值 Kafka 1.0.0 正式版本發布之際，我們梳理了一下公眾號上已發布的 Kafka 技術乾貨，並選出了部分精華文章，希望能幫助大家溫故而知新。

崛起的 Kafka

Kafka 起初是由 LinkedIn 公司開發的一個分散式的消息系統，後成為 Apache 的一部分，它使用 Scala 編寫，以可水平擴展和高吞吐率而被廣泛使用。目前越來越多的開源分散式處理系統如 Cloudera、Apache Storm、Spark 等都支持與 Kafka 集成。

隨著微服務的流行，很多公司都在嘗試將現有的系統進行架構升級。促成 Movio 公司架構改造的一項關鍵技術就是 Kafka 消息隊列。

Kafka 作為分散式消息隊列，在可靠性和可擴展性方面有非常大的優勢。它不僅成為了 Movio 公司基礎架構的關鍵組成部分，還為正在創建的系統架構提供了依據。

本文譯自 Braedon Vickers 發布在 Movio 上的一篇文章，詳盡地探討了在微服務架構升級的過程中，如何使用 Kafka 將微服務之間的耦合降到最低，同時能讓整個系統在保證高可用的前提下做到高可擴展。

微服務架構界的「網紅」來了——崛起的 Kafka

Kafka 全面解析

Kafka 數據可靠性深度解讀

Kafka 作為一個商業級消息中間件，消息可靠性的重要性可想而知。如何確保消息的精確傳輸？如何確保消息的準確存儲？如何確保消息的正確消費？這些都是需要考慮的問題。

唯品會消息中間件團隊首先從 Kafka 的架構著手，解釋了 Kafka 的基本原理，然後通過對 kakfa 的存儲機制、複製原理、同步原理、可靠性和持久性保證等等一步步對其可靠性進行分析，最後通過 benchmark 來增強對 Kafka 高可靠性的認知。

kafka 數據可靠性深度解讀

Kafka Stream 設計詳解

本文介紹了 Kafka Stream 的背景，如 Kafka Stream 是什麼，什麼是流式計算，以及為什麼要有 Kafka Stream。接著介紹了 Kafka Stream 的整體架構、並行模型、狀態存儲以及主要的兩種數據集 KStream 和 KTable。然後分析了 Kafka Stream 如何解決流式系統中的關鍵問題，如時間定義、窗口操作、Join 操作、聚合操作，以及如何處理亂序和提供容錯能力。最後結合示例講解了如何使用 Kafka Stream。

流式計算新貴 Kafka Stream 設計詳解

Kafka 不只是個消息系統

Confluent 聯合創始人兼 CEO Jay Kreps 發表了一篇博文，指出了 Kafka 的真正定位——它不只是個消息系統，它還是個存儲系統，而它的終極目標是要讓流式處理成為現代企業的主流開發範式。

人們更多的是把 Kafka 當成了消息隊列系統。消息隊列有一些不成文的規則，比如「不要在消息隊列里保存消息」。傳統的消息系統在設計上存在很多不足。從根本上講，任何一個非同步消息系統都會保存消息，只是時間很短，有時候只有幾秒鐘，直到消息被消費為止。

實際上，Kafka 並非傳統意義上的消息隊列，它與 RabbitMQ 等消息系統並不一樣。它更像是一個分散式的文件系統或資料庫。Kafka 與傳統消息系統之間有三個關鍵區別。

  • Kafka 持久化日誌，這些日誌可以被重複讀取和無限期保留
  • Kafka 是一個分散式系統：它以集群的方式運行，可以靈活伸縮，在內部通過複製數據提升容錯能力和高可用性
  • Kafka 支持實時的流式處理

以上三點足以將 Kafka 與傳統的消息隊列區別開，我們甚至可以把它看成是流式處理平台。因此，在 Kafka 里存儲數據並不是什麼瘋狂事，甚至可以說 Kafka 本來就是設計用來存儲數據的。數據經過校驗後被持久化在磁碟上，並通過複製副本提升容錯能力。再多的數據都不會拖慢 Kafka，在生產環境中，有些 Kafka 集群甚至已經保存超過 1 TB 的數據。

Kafka 不只是個消息系統

在本次正式版本發布之前，Confluent 在 8 月份的 Kafka Summit 大會上宣布開源用於 Kafka 的流數據 SQL 引擎，而 LinkedIn 也開源了 Kafka 伺服器集群的自動化運維工具 Cruse Control。

重磅開源 KSQL：用於 Apache Kafka 的流數據 SQL 引擎

開源 Cruise Control：LinkedIn 1800 台 Kafka 伺服器集群的自動化運維利器

Kafka 實戰指南

Kafka 憑藉著自身的優勢，越來越受到互聯網企業的青睞。AI 前線集結了紐約時報、Uber、LinkedIn 等公司在實戰中應用 Kafka 的技術乾貨，希望能夠幫助大家在公司實際業務中高效落地 Kafka。

紐約時報 Kafka 架構實戰

紐約時報有很多內容生成系統，我們使用第三方數據來編寫故事。另外，我們有 161 年的新聞行業積累和 21 年的在線內容發布經驗，所以大量的在線內容需要被搜索到，並提供給不同的服務和應用使用。

另一方面，有很多服務和應用需要訪問到這些內容——搜索引擎、個性化定製服務、新聞種子生成器，以及其他各種前端應用，如網站和移動應用。一旦有新內容發布，就要在很短的時間內讓這些服務訪問到，而且不能有數據丟失——畢竟這些內容都是有價值的新聞。

這篇文章將詳細介紹紐約時報是如何基於 Apache Kafka 解決上述問題的。

紐約時報 Kafka 架構實戰

Linkedln 的流處理生態和 Kafka「危機故障」

Apache Kafka 在 LinkedIn 是作為各種數據管道和非同步消息的後端被使用的。除了 LinkedIn，Netflix 和 Microsoft 也是 Kafka 的重量級使用者（Four Comma Club，每天萬億級別的消息量）。

隨著 Kafka 的使用率持續地快速增長，有一些重大問題漸漸浮現出來，所以 LinkedIn 圍繞 Kafka 開發了一個完整的生態系統。本文總結了 LinkedIn 的一些解決方案，希望能對正在使用 Kafka 的人有一些幫助。

漲姿勢：你用 Kafka 嗎？看看 LinkedIn 的流處理生態

雖然 Kafka 有著極其穩定的架構，但是在每天萬億級別消息量的大規模下也會偶爾出現有趣的 bug。本文深度分析了過去幾年在 LinkedIn 所遭遇的重大「危機故障」。在這裡闡述 Kafka 的「重大」bug 產生的根本原因（多種 bug、不正常的客戶端行為和監控不當多種因素相互作用導致的）是「後見之明」（有點像「馬後炮」的意思），但分享出來可以給廣大同仁以借鑒。

本文將講述如何探測、研究和修復這些問題，並總結出 Kafka 的一些特色以供將來消除或者減緩類似的 bug。

剖析 Linkedln 遭遇的 Kafka「危機故障」

Uber 如何對 Kafka 進行端到端審計

隨著 Uber 業務規模不斷增長，系統也在持續不斷地產生更多的事件、服務間的消息和日誌。這些數據在得到處理之前需要經過 Kafka。那麼 Uber 的平台是如何實時地對這些數據進行審計的呢？

為了監控 Kafka 數據管道的健康狀況並對流經 Kafka 的每個消息進行審計，Uber 完全依賴於審計系統 Chaperone，並且已經其開源。Chaperone 自 2016 年 1 月成為 Uber 的跨數據中心基礎設施以來，每天處理萬億的消息量。本文會介紹它的工作原理，並說明 Uber 為什麼會構建 Chaperone。

開源「Chaperone」：Uber 是如何對 Kafka 進行端到端審計的

－全文完－

關注人工智慧的落地實踐，與企業一起探尋 AI 的邊界，AICon 全球人工智慧技術大會火熱售票中，8 折倒計時一周搶票，詳情點擊：

t.cn/Rl2MftP

《深入淺出TensorFlow》迷你書現已發布，關注公眾號「AI前線」，ID：ai-front，回復關鍵字：TF，獲取下載鏈接！


推薦閱讀：

※大數據平台開發人員的核心競爭力是什麼？
※kafka中的topic為什麼要進行分區?

TAG:Kafka | 版本 | 更新 |