Twitter將遷移到Kafka
Twitter系統的實時性質為Twitter工程團隊帶來了獨特而具有挑戰性的問題。我們需要快速釋出突發新聞，向用戶提供相關廣告，並解決許多其他實時用例。Twitter的Pub / Sub系統為Twitter團隊提供了處理此工作負載的基礎架構。
Twitter的Messaging團隊過去幾年一直在執行一個內部Pub / Sub系統EventBus（建立在ofollow,noindex" target="_blank">Apache DistributedLog 之上），但我們最近決定轉向Apache Kafka，在這篇博文中，我們將討論為什麼我們選擇採用Kafka作為Twitter的Pub / Sub系統以及我們在此過程中遇到的不同挑戰。
什麼是卡夫卡？
Apache Kafka 是一個開源的分散式流媒體平臺，可以以高吞吐量和低延遲傳輸資料。Kafka最初是在LinkedIn構思並於2011年開源的，並且從那時起被社群廣泛採用，包括在其他公司，使其成為業界首選的事實上的實時訊息系統。
Kafka的核心是基於日誌 構建的Pub / Sub系統 ，具有許多理想的屬性，例如水平可伸縮性和容錯性。從那以後，Kafka已經從訊息系統發展成為一個成熟的流媒體平臺（參見Kafka Streams ）。
為什麼遷移？
您可能想知道為什麼Twitter首先選擇構建內部訊息傳遞系統。Twitter幾年前實際上使用過Kafka（0.7），但是我們發現了它不適合我們的用例的問題 - 主要是在追趕讀取期間進行的I / O操作的數量以及缺乏永續性和複製。然而，硬體和卡夫卡都已經經過了漫長的發展道路，現在已經解決了這些問題。
硬體的改進已經使SSD的價格足夠便宜，這有助於我們在HDD上看到的隨機讀取的先前I / O問題，並且伺服器NIC具有更多的頻寬，使得分割服務和儲存的吸引力降低圖層（EventBus）。此外，較新版本的Kafka現在支援資料複製，提供我們想要的持久耐用性保證。
將所有Twitter的Pub / Sub用例遷移到一個全新的系統將是一個昂貴的過程。所以，自然而言，搬到卡夫卡的決定不是自發的，而是經過精心策劃和資料驅動。遷移到卡夫卡的動機可歸納為兩個主要原因：成本和社群。
成本
在整個公司宣佈搬到Kafka的決定之前，我們的團隊花了幾個月的時間評估Kafka比較我們執行在EventBus上的類似工作負載 - 持久寫入，拖尾讀取，追趕讀取和高扇出讀取，以及一些灰色故障情況（例如，減慢群集中的特定代理）。
在效能方面，我們看到Kafka的延遲顯著降低，無論吞吐量如何，從訊息建立時到消費者閱讀訊息時的時間戳差異來衡量。
這可歸因於幾個因素，可能包括但不限於：
- 在EventBus中，服務層和儲存層是分離的，這引入了額外的跳（網路時間和時間都通過JVM代理層），而在Kafka中只有一個程序處理儲存和請求服務（參見下圖） ）。
- EventBus顯式阻止對fsync（）呼叫的寫入，而Kafka在後臺依賴作業系統到fsync（）。
- 卡夫卡使用零拷貝 。
從成本的角度來看，EventBus需要服務層（針對高網路吞吐量進行了優化）和儲存層（針對磁碟進行了優化）的硬體，而Kafka使用單個主機來提供這兩者。因此，EventBus需要更多的機器才能來提供與Kafka相同的工作負載。
對於單個消費者用例，我們節省 了68％的資源 ，對於擁有多個消費者的扇出案例，我們節省 了75％的資源 。
一個問題是，對於極其頻寬繁重的工作負載（非常高的扇出fanout 讀取），EventBus理論上可能更有效，因為我們可以獨立地擴充套件服務層。但是，我們在實踐中發現，我們的扇出不夠極端，不值得分離服務層，特別是考慮到現代硬體上的可用頻寬。
社群
如上所述，卡夫卡已被廣泛採用。這有助於我們首先讓我們利用數百名開發人員為Kafka專案做出貢獻的錯誤修復，改進和新功能，而不是工作在EventBus / DistributedLog上的八名工程師。此外，我們的Twitter客戶在EventBus中想要的許多功能已經在Kafka中構建，例如流媒體庫，至少一次HDFS管道，以及一次性處理。
此外，當我們在客戶端或伺服器上遇到問題時，我們可以通過快速搜尋網路輕鬆找到解決方案，因為很可能其他人遇到了同樣的問題。同樣，對於不太受歡迎的專案來說，採用良好的專案的文件通常比文件更詳盡。
採用和回饋卡夫卡等熱門專案的另一個重要方面是招聘目的。一方面，通過回饋卡夫卡，人們可以瞭解Twitter的工程。另一方面，由於新工程師已經熟悉該技術，因此為團隊招聘工程師要容易得多。這消除了EventBus所需的任何必要的加速時間。
挑戰
儘管轉移到卡夫卡的聲音，但這並不是一帆風順的。我們在這個過程中遇到了許多技術挑戰和適應性挑戰。
從技術角度來看，我們遇到的一些挑戰包括配置調優和Kafka Streams庫。與許多分散式系統一樣，為了支援Twitter的實時用例，需要對大量配置進行微調。在執行Kafka Streams時，我們發現Kafka Streams庫中的元資料大小存在一些問題，這些問題是由於過時的客戶端在關閉後仍然保留其元資料。
另一方面，Kafka與EventBus存在架構差異，這要求我們以不同方式配置系統和除錯問題。這方面的一個例子是如何在EventBus（仲裁寫入）和Kafka（主從複製）中完成複製。寫請求在EventBus中並行傳送，而Kafka要求從節點僅在主機收到寫請求後才複製寫請求。此外，兩個系統之間的永續性模型是非常不同的 - EventBus僅在資料持久化（fsync'd）到磁碟時確認寫入，而Kafka表明複製本身將保證永續性並且資料持久儲存在磁碟上之前就確認寫入請求。
期待
在接下來的幾個月裡，我們的計劃是將我們的客戶從EventBus遷移到Kafka，這將有助於降低運營Twitter Pub / Sub系統的成本，並使我們的客戶能夠使用Kafka提供的其他功能。我們將持續關注生態系統中的不同訊息傳遞和流媒體系統，並確保我們的團隊為我們的客戶和Twitter做出正確的決策，即使這是一個艱難的決定。