推特最近把原本內部開發的Pub/Sub系統EventBus更換成Apache Kafka ，除了在成本上，當有許多用戶都要轉推發文的情況下（數據處理上稱為fan-out），能節省高達75%的資源外，由於Kafka龐大社群的資源，修復錯誤和增加新功能更快，也更容易找到系統維護工程師人選。
Apache Kafka是一個開源分佈式串流平臺，能以高吞吐量低延遲方式傳輸數據。Ka
fka的核心是基於日誌構建的Pub/Sub系統，具有可水平伸縮和容錯性，是用來打造即時新聞系統的理想選擇。但其實推特在幾年前就已經使用過Kafka，推特發現當時Kafka 0.7版本，有幾個不適合他們使用場景的缺點，主要是在追趕讀取（Catchup Reads）期間的I/O操作數限制，也欠缺耐久性和複製功能。
由於當時使用Kafka的這些限制，推特基於Apache DistributedLog，打造了自己的Pub/Sub系統EventBus，以應對推特快速發佈突發新聞、對用戶提供相關廣告，以及其他即時使用案例的需求。
時至今日，硬件和Kafka項目在經過時間的發展，推特之前遇到的問題，都已經獲得解決。SSD的價格已經足夠低廉，有助於解決之前在HDD上遇到隨機讀取先前I/O的問題，而且服務器NICs具有更大的帶寬，使得EventBus的分割服務和存儲層的好處消失。新版的Kafka現在還支持數據複製，提供推特需要的數據耐久性保證。推特表示，驅動他們把Pub/Sub系統從EventBus搬遷到Kafka上，主要是考察成本以及社群兩個原因。
在推特決定要搬遷Pub/Sub系統到Kafka之前，團隊花了數個月評價，他們在Kafka上運行相近於EventBus上的工作負載，包括耐久寫入、長尾讀取（Tailing reads）、追趕讀取以及高扇出讀取（High Hanout Reads），還有一些灰色故障的場景。從數據串流消費者讀取信息的時間戳差異來衡量，無論吞吐量如何，Kafka的延遲都明顯較低，推特提到，這可以歸因成三個原因，第一個，由於在推特原本使用的EventBus，服務層和存儲層是分離的，因此產生額外的跳躍（Hop），而Kafka只用一個程序處理存儲和請求服務。
第二個原因，EventBus明顯地阻止對fsync（）調用寫入，但是Kafka卻依賴操作系統背景進行fsync（）調用。第三個原因是，Kafka使用零複製（Zero-copy）。因此從成本的角度來看，EventBus需要服務層和存儲層的硬件，分別針對高網絡吞吐量和硬盤進行優化，但Kafka只需要使用單一主機，推特提到，顯然EventBus需要更多的機器才能達到和Kafka相同的工作負載。
單一數據串流消費者的使用案例，Kafka可以節省68%的資源，當有多個用戶發文並轉推給他們所有友人時的fan-out情況下，推特估計，則能節省高達75%的資源。推特表示，由於他們使用案例fan-out效應不夠極端，在實例中不值得分離服務層，特別是考慮到現代硬件上的可用帶寬，否則在理論上EventBus應該更有效率。
除了成本上的考察，Kafka龐大的支持社群也是一大優勢。在推特中，維護EventBus系統的只有8名工程師，但是Kafka項目現在卻有數百人進行維護，幫忙修復錯誤和增加新功能。推特預計在EventBus增加的新功能，像是串流函數庫、至少一次HDFS工作管線以及一次性處理都已經在Kafka中具備了。
此外，在客戶端或是服務器發生問題時，開發人員可以參考其他團隊的經驗，快速的解決問題，而且也因為Kafka是一個熱門項目，因此瞭解Kafka的工程師數量也比較多，方便招聘系統工程師。在接下來的幾個月內，推特計劃開始把用戶從EventBus遷移到Kafka上，以降低運營成本，並且讓用戶獲得Kafka提供的其他功能。
閱讀更多 十輪網 的文章
