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