為什麼Twitter決定採用kafka作為其釋出訂閱系統？

什麼是卡夫卡？

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（）。
• 卡夫卡使用零複製。

社群
如上所述，卡夫卡已被廣泛採用。這有助於我們首先讓我們利用數百名開發人員為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做出正確的決策，即使這是一個艱難的決定。