Twitter 的實(shí)時(shí)性特點(diǎn)為 Twitter 的工程團(tuán)隊(duì)帶來了獨(dú)特而具有挑戰(zhàn)性的問題。我們需要快速發(fā)布突發(fā)新聞，向用戶提供相關(guān)廣告，并解決很多其他實(shí)時(shí)性問題。Twitter 的 Pub/Sub 系統(tǒng)為 Twitter 團(tuán)隊(duì)提供了處理這些工作負(fù)載的基礎(chǔ)設(shè)施。

Twitter 的 Messaging 團(tuán)隊(duì)過去幾年一直在運(yùn)行一個(gè)內(nèi)部 Pub/Sub 系統(tǒng)，叫作 EventBus(建立在 Apache DistributedLog 之上)，但我們最近決定轉(zhuǎn)向 Apache Kafka，不僅針對(duì)已有的用例，還包括新增的用例。在這篇文章中，我們將介紹為什么我們選擇采用 Kafka 作為 Twitter 的 Pub/Sub 系統(tǒng)，以及我們?cè)谶w移過程中遇到的各種挑戰(zhàn)。

Kafka 是什么?

Apache Kafka 是一個(gè)開源的分布式流式處理平臺(tái)，可以高吞吐和低延遲地傳輸數(shù)據(jù)。Kafka 最初是在 LinkedIn 誕生，并于 2011 年開源，從那時(shí)起開始被社區(qū)廣泛采用，包括很多其他公司在內(nèi)，使其成為業(yè)界首選的事實(shí)上的實(shí)時(shí)消息系統(tǒng)。

Kafka 的核心就是一個(gè)基于分布式提交日志構(gòu)建的 Pub/Sub 系統(tǒng)，提供了很多非常好的特性，例如水平可伸縮性和容錯(cuò)性。從那以后，Kafka 已經(jīng)從消息系統(tǒng)發(fā)展成為一個(gè)成熟的流式處理平臺(tái)。

為什么要遷移?

你可能想知道為什么 Twitter 需要自己構(gòu)建內(nèi)部的消息傳遞系統(tǒng)。幾年前，Twitter 也曾經(jīng)使用過 Kafka(0.7 版本)，但我們發(fā)現(xiàn)在某些方面它無法滿足我們的要求——主要是在讀取期間進(jìn)行的 I/O 操作數(shù)量，而且缺乏持久化特性和復(fù)制機(jī)制。然而，隨著時(shí)間推移，硬件和 Kafka 都已經(jīng)走過了漫長的道路，這些問題現(xiàn)在都已經(jīng)得到了解決。硬件的改進(jìn)已經(jīng)使 SSD 的價(jià)格足夠便宜，這解決了我們之前在 HDD 上看到的隨機(jī)讀取的 I/O 問題，而且服務(wù)器 NIC 具有更多的帶寬，就沒有那么必要分離服務(wù)和存儲(chǔ)層(EventBus 會(huì)這么做)。此外，較新版本的 Kafka 現(xiàn)在支持?jǐn)?shù)據(jù)復(fù)制，提供了我們想要的持久性保證。

將 Twitter 的所有 Pub/Sub 用例遷移到一個(gè)全新的系統(tǒng)將是一個(gè)非常耗費(fèi)成本的過程。所以，遷移到 Kafka 的決定絕對(duì)不是自然發(fā)生的，而是經(jīng)過精心策劃的，并且是由數(shù)據(jù)驅(qū)動(dòng)的。遷移到 Kafka 的動(dòng)機(jī)可歸納為兩個(gè)方面：成本和社區(qū)。

成本

在向整個(gè)公司宣布遷移到 Kafka 之前，我們的團(tuán)隊(duì)花了幾個(gè)月時(shí)間評(píng)估了 Kafka 在與 EventBus 類似的工作負(fù)載下的表現(xiàn)——持久寫入、尾部讀取、追趕讀取和高扇出讀取，以及一些灰色故障情況(例如減慢集群中的特定 Kafka 代理)。

在性能方面，我們看到 Kafka 的延遲顯著降低，無論是根據(jù)消息創(chuàng)建時(shí)間戳來衡量吞吐量，還是根據(jù)消費(fèi)者讀取消息時(shí)間戳來衡量吞吐量。

 

 

不同吞吐量下 EventBus 和 Kafka 之間的 P99 延遲比較

這可以歸因于幾個(gè)因素，可能包括但不限于：

在 EventBus 中，服務(wù)層和存儲(chǔ)層是分離的，這引入了額外的跳轉(zhuǎn)(網(wǎng)絡(luò)時(shí)間和通過 JVM 代理層的時(shí)間)，而在 Kafka 中只有一個(gè)進(jìn)程處理存儲(chǔ)和請(qǐng)求服務(wù)(參見下圖)。

EventBus 在通過 fsync() 調(diào)用進(jìn)行寫入時(shí)會(huì)阻塞，而 Kafka 在后臺(tái)依賴操作系統(tǒng)進(jìn)行 fsync()。

Kafka 使用零拷貝。

 

 

EventBus(左)和 Kafka(右)之間的架構(gòu)比較

從成本的角度來看，EventBus 需要服務(wù)層(針對(duì)高網(wǎng)絡(luò)吞吐量進(jìn)行了優(yōu)化)和存儲(chǔ)層(針對(duì)磁盤進(jìn)行了優(yōu)化)的硬件，而 Kafka 使用單臺(tái)主機(jī)就可以提供這兩者。因此，EventBus 需要更多的機(jī)器來提供與 Kafka 相同的工作負(fù)載。對(duì)于單個(gè)消費(fèi)者，我們節(jié)省了 68%的資源，對(duì)于擁有多個(gè)消費(fèi)者的案例，我們節(jié)省了 75%的資源。但有一個(gè)問題是，對(duì)于嚴(yán)重依賴帶寬的工作負(fù)載(非常高的扇出讀取)，EventBus 理論上可能更有效，因?yàn)槲覀兛梢元?dú)立地?cái)U(kuò)展服務(wù)層。但是，我們?cè)趯?shí)踐中發(fā)現(xiàn)，我們的扇出沒有那么極端，分離服務(wù)層是不值得的。

社區(qū)

如上所述，Kafka 已經(jīng)得到了廣泛采用。我們可以利用數(shù)百名開發(fā)人員為 Kafka 項(xiàng)目所做出的貢獻(xiàn)，他們修復(fù)錯(cuò)誤、改進(jìn)和添加新功能，這比 EventBus/DistributedLog 的八名工程師所做的要好得多。此外，Twitter 內(nèi)部用戶在 EventBus 中想要的很多功能已經(jīng)在 Kafka 中提供了，例如流式處理庫、至少一次 HDFS 管道，以及恰好一次性處理。

此外，當(dāng)我們遇到客戶端或服務(wù)器問題時(shí)，我們可以通過搜索網(wǎng)絡(luò)輕松快速地找到解決方案，因?yàn)楹芸赡芷渌�人之前也遇到了同樣的問題。另外，相比不太受歡迎的項(xiàng)目，受歡迎的項(xiàng)目的文檔通常更加詳盡。

采用 Kafka 等熱門項(xiàng)目，并向這些項(xiàng)目回饋我們的貢獻(xiàn)，這樣做的另一個(gè)重要原因是為了招聘。一方面，通過向 Kafka 社區(qū)回饋貢獻(xiàn)，可以讓人們了解 Twitter 的工程。另一方面，由于新工程師已經(jīng)熟悉了這些技術(shù)，因此為團(tuán)隊(duì)招聘工程師要容易得多。

挑戰(zhàn)

盡管遷移到 Kafka 看起來非常棒，但過程并不是一帆風(fēng)順的。我們?cè)谶@個(gè)過程中遇到了很多技術(shù)挑戰(zhàn)和適應(yīng)性挑戰(zhàn)。

從技術(shù)角度來看，我們遇到的一些挑戰(zhàn)包括配置調(diào)優(yōu)和 Kafka Streams 庫。與很多分布式系統(tǒng)一樣，為了支持 Twitter 的實(shí)時(shí)性用例，需要對(duì)大量配置進(jìn)行微調(diào)。在運(yùn)行 Kafka Streams 時(shí)，我們發(fā)現(xiàn) Kafka Streams 庫中的元數(shù)據(jù)大小存在一些問題，這些問題是由于老版本的客戶端在關(guān)閉后仍然保留元數(shù)據(jù)造成的。

另一方面，Kafka 與 EventBus 存在架構(gòu)差異，我們不得不以不同的方式配置系統(tǒng)和調(diào)試問題。例如，如何在 EventBus(仲裁寫入)和 Kafka(主從復(fù)制)中完成復(fù)制。寫請(qǐng)求在 EventBus 中并行發(fā)送，而 Kafka 要求從節(jié)點(diǎn)僅在主節(jié)點(diǎn)收到寫請(qǐng)求后才復(fù)制寫請(qǐng)求。此外，兩個(gè)系統(tǒng)之間的持久性模型是非常不同的—— EventBus 僅在數(shù)據(jù)持久化到磁盤時(shí)確認(rèn)寫入成功，而 Kafka 復(fù)制本身就具有持久性保證，并在將數(shù)據(jù)持久存儲(chǔ)在磁盤上之前確認(rèn)寫入請(qǐng)求。我們不得不重新考慮我們對(duì)數(shù)據(jù)持久性的定義：數(shù)據(jù)的所有三個(gè)副本同時(shí)失敗是不太可能的，因此沒有必要在每個(gè)副本中同步數(shù)據(jù)來提供我們想要的持久性保證。

前行

在接下來的幾個(gè)月里，我們計(jì)劃將我們的用戶從 EventBus 遷移到 Kafka，這將有助于降低運(yùn)營 Twitter Pub/Sub 系統(tǒng)的成本，并使我們的用戶能夠使用 Kafka 提供的其他功能。我們將持續(xù)關(guān)注生態(tài)系統(tǒng)中的不同消息傳遞和流式處理系統(tǒng)，并確保我們的團(tuán)隊(duì)為我們的用戶和 Twitter 做出正確的決策，即使這些決策很艱難。

英文原文：

https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story.html

標(biāo)簽： ssd 服務(wù)器 搜索 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。