Twitter的實時性特點爲Twitter的工程團隊帶來了獨特而具有挑戰性的問題。我們需要快速發佈突發新聞，向用戶提供相關廣告，並解決很多其他實時性問題。Twitter的Pub/Sub系統爲Twitter團隊提供了處理這些工作負載的基礎設施。
Twitter的Messaging團隊過去幾年一直在運行一個內部Pub/Sub系統，叫作EventBus（建立在Apache DistributedLog之上），但我們最近決定轉向Apache Kafka，不僅針對已有的用例，還包括新增的用例。在這篇文章中，我們將介紹爲什麼我們選擇採用Kafka作爲Twitter的Pub/Sub系統，以及我們在遷移過程中遇到的各種挑戰。
Kafka是什麼？
Apache Kafka是一個開源的分佈式流式處理平臺，可以高吞吐和低延遲地傳輸數據。Kafka最初是在LinkedIn誕生，並於2011年開源，從那時起開始被社區廣泛採用，包括很多其他公司在內，使其成爲業界首選的事實上的實時消息系統。
Kafka的核心就是一個基於分佈式提交日誌構建的Pub/Sub系統，提供了很多非常好的特性，例如水平可伸縮性和容錯性。從那以後，Kafka已經從消息系統發展成爲一個成熟的流式處理平臺。
爲什麼要遷移？
你可能想知道爲什麼Twitter需要自己構建內部的消息傳遞系統。幾年前，Twitter也曾經使用過Kafka（0.7版本），但我們發現在某些方面它無法滿足我們的要求——主要是在讀取期間進行的I/O操作數量，而且缺乏持久化特性和複製機制。然而，隨着時間推移，硬件和Kafka都已經走過了漫長的道路，這些問題現在都已經得到了解決。硬件的改進已經使SSD的價格足夠便宜，這解決了我們之前在HDD上看到的隨機讀取的I/O問題，而且服務器NIC具有更多的帶寬，就沒有那麼必要分離服務和存儲層（EventBus會這麼做）。此外，較新版本的Kafka現在支持數據複製，提供了我們想要的持久性保證。
將Twitter的所有Pub/Sub用例遷移到一個全新的系統將是一個非常耗費成本的過程。所以，遷移到Kafka的決定絕對不是自然發生的，而是經過精心策劃的，並且是由數據驅動的。遷移到Kafka的動機可歸納爲兩個方面：成本和社區。
成本
在向整個公司宣佈遷移到Kafka之前，我們的團隊花了幾個月時間評估了Kafka在與EventBus類似的工作負載下的表現——持久寫入、尾部讀取、追趕讀取和高扇出讀取，以及一些灰色故障情況（例如減慢集羣中的特定Kafka代理）。
在性能方面，我們看到Kafka的延遲顯著降低，無論是根據消息創建時間戳來衡量吞吐量，還是根據消費者讀取消息時間戳來衡量吞吐量。
不同吞吐量下EventBus和Kafka之間的P99延遲比較
這可以歸因於幾個因素，可能包括但不限於：
- 在EventBus中，服務層和存儲層是分離的，這引入了額外的跳轉（網絡時間和通過JVM代理層的時間），而在Kafka中只有一個進程處理存儲和請求服務（參見下圖）。
- EventBus在通過fsync()調用進行寫入時會阻塞，而Kafka在後臺依賴操作系統進行fsync()。
- Kafka使用零拷貝。
EventBus（左）和Kafka（右）之間的架構比較
從成本的角度來看，EventBus需要服務層（針對高網絡吞吐量進行了優化）和存儲層（針對磁盤進行了優化）的硬件，而Kafka使用單臺主機就可以提供這兩者。因此，EventBus需要更多的機器來提供與Kafka相同的工作負載。對於單個消費者，我們節省了68％的資源，對於擁有多個消費者的案例，我們節省了75％的資源。但有一個問題是，對於嚴重依賴帶寬的工作負載（非常高的扇出讀取），EventBus理論上可能更有效，因爲我們可以獨立地擴展服務層。但是，我們在實踐中發現，我們的扇出沒有那麼極端，分離服務層是不值得的。
社區
如上所述，Kafka已經得到了廣泛採用。我們可以利用數百名開發人員爲Kafka項目所做出的貢獻，他們修復錯誤、改進和添加新功能，這比EventBus/DistributedLog的八名工程師所做的要好得多。此外，Twitter內部用戶在EventBus中想要的很多功能已經在Kafka中提供了，例如流式處理庫、至少一次HDFS管道，以及恰好一次性處理。
此外，當我們遇到客戶端或服務器問題時，我們可以通過搜索網絡輕鬆快速地找到解決方案，因爲很可能其他人之前也遇到了同樣的問題。另外，相比不太受歡迎的項目，受歡迎的項目的文檔通常更加詳盡。
採用Kafka等熱門項目，並向這些項目回饋我們的貢獻，這樣做的另一個重要原因是爲了招聘。一方面，通過向Kafka社區回饋貢獻，可以讓人們瞭解Twitter的工程。另一方面，由於新工程師已經熟悉了這些技術，因此爲團隊招聘工程師要容易得多。
挑戰
儘管遷移到Kafka看起來非常棒，但過程並不是一帆風順的。我們在這個過程中遇到了很多技術挑戰和適應性挑戰。
從技術角度來看，我們遇到的一些挑戰包括配置調優和Kafka Streams庫。與很多分佈式系統一樣，爲了支持Twitter的實時性用例，需要對大量配置進行微調。在運行Kafka Streams時，我們發現Kafka Streams庫中的元數據大小存在一些問題，這些問題是由於老版本的客戶端在關閉後仍然保留元數據造成的。
另一方面，Kafka與EventBus存在架構差異，我們不得不以不同的方式配置系統和調試問題。例如，如何在EventBus（仲裁寫入）和Kafka（主從複製）中完成複製。寫請求在EventBus中並行發送，而Kafka要求從節點僅在主節點收到寫請求後才複製寫請求。此外，兩個系統之間的持久性模型是非常不同的—— EventBus僅在數據持久化到磁盤時確認寫入成功，而Kafka複製本身就具有持久性保證，並在將數據持久存儲在磁盤上之前確認寫入請求。我們不得不重新考慮我們對數據持久性的定義：數據的所有三個副本同時失敗是不太可能的，因此沒有必要在每個副本中同步數據來提供我們想要的持久性保證。
前行
在接下來的幾個月裏，我們計劃將我們的用戶從EventBus遷移到Kafka，這將有助於降低運營Twitter Pub/Sub系統的成本，並使我們的用戶能夠使用Kafka提供的其他功能。我們將持續關注生態系統中的不同消息傳遞和流式處理系統，並確保我們的團隊爲我們的用戶和Twitter做出正確的決策，即使這些決策很艱難。
英文原文：
https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story.html