作者：Natalie & Vincent
Kafka 從首次發(fā)布之日起，已經走過了七個年頭。從最開始的大規(guī)模消息系統(tǒng)，發(fā)展成為功能完善的分布式流式處理平臺，用于發(fā)布和訂閱、存儲及實時地處理大規(guī)模流數據。來自世界各地的數千家公司在使用 Kafka，包括三分之一的 500 強公司。Kafka 以穩(wěn)健的步伐向前邁進，首先加入了復制功能和無邊界的鍵值數據存儲，接著推出了用于集成外部存儲系統(tǒng)的 Connect API，后又推出了為實時應用和事件驅動應用提供原生流式處理能力的 Streams API，并于今年春季開始支持僅一次處理語義。如此廣泛的應用和完備的功能以及如此悠久的歷史，無一不在說明 Kafka 已經成為一款穩(wěn)定的企業(yè)級產品。而更為激動人心的是，Kafka 現在正式迎來了 1.0.0 版本！
Kafka 1.0.0 發(fā)布的主要內容如下：
0.10.0 版本里開始引入的 Streams API 在 1.0.0 版本里繼續(xù)演進，改進了 builder API（KIP-120），新增了用于查看運行時活躍任務的 API（KIP-130）和用于聚合分區(qū)的 cogroup API（KIP-150）。增強的 print() 和 writeAsText() 方法讓調試變得更容易（KIP-160）。其他更多信息可以參考 Streams 文檔。
改進了 Connect 的度量指標（KIP-196），新增了大量用于健康監(jiān)測的度量指標（KIP-188），并提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指標（KIP-168）。
支持 Java 9，實現更快的 TLS 和 CRC32C，加快了加密速度，降低了計算開銷。
調整了 SASL 認證模塊的錯誤處理邏輯（KIP-152），原先的認證錯誤信息現在被清晰地記錄到日志當中。
更好地支持磁盤容錯（KIP-112），更優(yōu)雅地處理磁盤錯誤，單個 JBOD 上的磁盤錯誤不會導致整個集群崩潰。
0.11.0 版本中引入的冪等性生產者需要將 max.in.flight.requests.per.connection 參數設置為 1，這對吞吐量造成了一定的限制。而在 1.0.0 版本里，這個參數最大可以被設置為 5（KAFKA-5949），極大提升了吞吐量范圍。
關于新版本更多的變化可以查看發(fā)布說明：
https://dist.apache.org/repos/dist/release/kafka/1.0.0/RELEASE_NOTES.html
下載源代碼：
https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka-1.0.0-src.tgz
二進制包
Scala 2.11：
https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka_2.11-1.0.0.tgz
Scala 2.12：
https://www.apache.org/dyn/closer.cgi?path=/kafka/1.0.0/kafka_2.12-1.0.0.tgz
正值 Kafka 1.0.0 正式版本發(fā)布之際，我們梳理了一下公眾號上已發(fā)布的 Kafka 技術干貨，并選出了部分精華文章，希望能幫助大家溫故而知新。
崛起的 Kafka
Kafka 起初是由 LinkedIn 公司開發(fā)的一個分布式的消息系統(tǒng)，后成為 Apache 的一部分，它使用 Scala 編寫，以可水平擴展和高吞吐率而被廣泛使用。目前越來越多的開源分布式處理系統(tǒng)如 Cloudera、Apache Storm、Spark 等都支持與 Kafka 集成。
隨著微服務的流行，很多公司都在嘗試將現有的系統(tǒng)進行架構升級。促成 Movio 公司架構改造的一項關鍵技術就是 Kafka 消息隊列。
Kafka 作為分布式消息隊列，在可靠性和可擴展性方面有非常大的優(yōu)勢。它不僅成為了 Movio 公司基礎架構的關鍵組成部分，還為正在創(chuàng)建的系統(tǒng)架構提供了依據。
本文譯自 Braedon Vickers 發(fā)布在 Movio 上的一篇文章，詳盡地探討了在微服務架構升級的過程中，如何使用 Kafka 將微服務之間的耦合降到最低，同時能讓整個系統(tǒng)在保證高可用的前提下做到高可擴展。
微服務架構界的“網紅”來了——崛起的 Kafka
Kafka 全面解析
Kafka 數據可靠性深度解讀
Kafka 作為一個商業(yè)級消息中間件，消息可靠性的重要性可想而知。如何確保消息的精確傳輸？如何確保消息的準確存儲？如何確保消息的正確消費？這些都是需要考慮的問題。
唯品會消息中間件團隊首先從 Kafka 的架構著手，解釋了 Kafka 的基本原理，然后通過對 kakfa 的存儲機制、復制原理、同步原理、可靠性和持久性保證等等一步步對其可靠性進行分析，最后通過 benchmark 來增強對 Kafka 高可靠性的認知。
kafka 數據可靠性深度解讀
Kafka Stream 設計詳解
本文介紹了 Kafka Stream 的背景，如 Kafka Stream 是什么，什么是流式計算，以及為什么要有 Kafka Stream。接著介紹了 Kafka Stream 的整體架構、并行模型、狀態(tài)存儲以及主要的兩種數據集 KStream 和 KTable。然后分析了 Kafka Stream 如何解決流式系統(tǒng)中的關鍵問題，如時間定義、窗口操作、Join 操作、聚合操作，以及如何處理亂序和提供容錯能力。最后結合示例講解了如何使用 Kafka Stream。
流式計算新貴 Kafka Stream 設計詳解
Kafka 不只是個消息系統(tǒng)
Confluent 聯(lián)合創(chuàng)始人兼 CEO Jay Kreps 發(fā)表了一篇博文，指出了 Kafka 的真正定位——它不只是個消息系統(tǒng)，它還是個存儲系統(tǒng)，而它的終極目標是要讓流式處理成為現代企業(yè)的主流開發(fā)范式。
人們更多的是把 Kafka 當成了消息隊列系統(tǒng)。消息隊列有一些不成文的規(guī)則，比如“不要在消息隊列里保存消息”。傳統(tǒng)的消息系統(tǒng)在設計上存在很多不足。從根本上講，任何一個異步消息系統(tǒng)都會保存消息，只是時間很短，有時候只有幾秒鐘，直到消息被消費為止。
實際上，Kafka 并非傳統(tǒng)意義上的消息隊列，它與 RabbitMQ 等消息系統(tǒng)并不一樣。它更像是一個分布式的文件系統(tǒng)或數據庫。Kafka 與傳統(tǒng)消息系統(tǒng)之間有三個關鍵區(qū)別。
Kafka 持久化日志，這些日志可以被重復讀取和無限期保留
Kafka 是一個分布式系統(tǒng)：它以集群的方式運行，可以靈活伸縮，在內部通過復制數據提升容錯能力和高可用性
Kafka 支持實時的流式處理
以上三點足以將 Kafka 與傳統(tǒng)的消息隊列區(qū)別開，我們甚至可以把它看成是流式處理平臺。因此，在 Kafka 里存儲數據并不是什么瘋狂事，甚至可以說 Kafka 本來就是設計用來存儲數據的。數據經過校驗后被持久化在磁盤上，并通過復制副本提升容錯能力。再多的數據都不會拖慢 Kafka，在生產環(huán)境中，有些 Kafka 集群甚至已經保存超過 1 TB 的數據。
Kafka 不只是個消息系統(tǒng)
在本次正式版本發(fā)布之前，Confluent 在 8 月份的 Kafka Summit 大會上宣布開源用于 Kafka 的流數據 SQL 引擎，而 LinkedIn 也開源了 Kafka 服務器集群的自動化運維工具 Cruse Control。
重磅開源 KSQL：用于 Apache Kafka 的流數據 SQL 引擎
開源 Cruise Control：LinkedIn 1800 臺 Kafka 服務器集群的自動化運維利器
Kafka 實戰(zhàn)指南
Kafka 憑借著自身的優(yōu)勢，越來越受到互聯(lián)網企業(yè)的青睞。AI 前線集結了紐約時報、Uber、LinkedIn 等公司在實戰(zhàn)中應用 Kafka 的技術干貨，希望能夠幫助大家在公司實際業(yè)務中高效落地 Kafka。
紐約時報 Kafka 架構實戰(zhàn)
紐約時報有很多內容生成系統(tǒng)，我們使用第三方數據來編寫故事。另外，我們有 161 年的新聞行業(yè)積累和 21 年的在線內容發(fā)布經驗，所以大量的在線內容需要被搜索到，并提供給不同的服務和應用使用。
另一方面，有很多服務和應用需要訪問到這些內容——搜索引擎、個性化定制服務、新聞種子生成器，以及其他各種前端應用，如網站和移動應用。一旦有新內容發(fā)布，就要在很短的時間內讓這些服務訪問到，而且不能有數據丟失——畢竟這些內容都是有價值的新聞。
這篇文章將詳細介紹紐約時報是如何基于 Apache Kafka 解決上述問題的。
紐約時報 Kafka 架構實戰(zhàn)
Linkedln 的流處理生態(tài)和 Kafka“危機故障”
Apache Kafka 在 LinkedIn 是作為各種數據管道和異步消息的后端被使用的。除了 LinkedIn，Netflix 和 Microsoft 也是 Kafka 的重量級使用者（Four Comma Club，每天萬億級別的消息量）。
隨著 Kafka 的使用率持續(xù)地快速增長，有一些重大問題漸漸浮現出來，所以 LinkedIn 圍繞 Kafka 開發(fā)了一個完整的生態(tài)系統(tǒng)。本文總結了 LinkedIn 的一些解決方案，希望能對正在使用 Kafka 的人有一些幫助。
漲姿勢：你用 Kafka 嗎？看看 LinkedIn 的流處理生態(tài)
雖然 Kafka 有著極其穩(wěn)定的架構，但是在每天萬億級別消息量的大規(guī)模下也會偶爾出現有趣的 bug。本文深度分析了過去幾年在 LinkedIn 所遭遇的重大“危機故障”。在這里闡述 Kafka 的“重大”bug 產生的根本原因（多種 bug、不正常的客戶端行為和監(jiān)控不當多種因素相互作用導致的）是“后見之明”（有點像“馬后炮”的意思），但分享出來可以給廣大同仁以借鑒。
本文將講述如何探測、研究和修復這些問題，并總結出 Kafka 的一些特色以供將來消除或者減緩類似的 bug。
剖析 Linkedln 遭遇的 Kafka“危機故障”
Uber 如何對 Kafka 進行端到端審計
隨著 Uber 業(yè)務規(guī)模不斷增長，系統(tǒng)也在持續(xù)不斷地產生更多的事件、服務間的消息和日志。這些數據在得到處理之前需要經過 Kafka。那么 Uber 的平臺是如何實時地對這些數據進行審計的呢？
為了監(jiān)控 Kafka 數據管道的健康狀況并對流經 Kafka 的每個消息進行審計，Uber 完全依賴于審計系統(tǒng) Chaperone，并且已經其開源。Chaperone 自 2016 年 1 月成為 Uber 的跨數據中心基礎設施以來，每天處理萬億的消息量。本文會介紹它的工作原理，并說明 Uber 為什么會構建 Chaperone。
- 特朗普宣布200億美元投資計劃，在美國多地建設數據中心
- 工信部：“點、鏈、網、面”體系化推進算力網絡工作 持續(xù)提升算網綜合供給能力
- 2025年超融合基礎設施的4大趨勢
- 2025年將影響數據中心的5個云計算趨勢
- 80萬輛大眾汽車因AWS云配置錯誤導致數據泄露，包含“高精度”位置記錄
- 名創(chuàng)優(yōu)品超4000家門店接入“碰一下”支付，引爆年輕消費熱潮
- 免稅店也能用“碰一下”支付了！中免海南免稅店：碰一下就優(yōu)惠
- 報告：人工智能推動數據中心系統(tǒng)支出激增25%
- 密態(tài)計算技術助力農村普惠金融 螞蟻密算、網商銀行項目入選大數據“星河”案例
- 專利糾紛升級！Netflix就虛擬機專利侵權起訴博通及VMware
免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
