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