如果我們需要持續地處理大約20萬條/秒的訊息量，同時還需要保證資料的可用性和冗餘，我們應該怎麼做呢？最近Tadas Vilkeliskis在自己的部落格上發表了一篇題為《資料流基礎設施》的文章，分享了他們是如何應對這種場景的。

Tadas Vilkeliskis在文章中提到，他們每秒鐘大約會收到來自於世界各地的20萬次HTTP請求，這些請求包含了使用者的行為資訊，平均每一條訊息的大小約為0.8KB，每秒鐘的總數量在150MB左右。為了應對如此高的流量，Tadas Vilkeliskis說他們的方案是Kafka：將這些HTTP請求當成一個事件流，先把接收到的所有請求都推動到Kafka訊息佇列中，然後再依次進行處理。其中，事件流中的所有請求都可以包含一些會隨時間變化的資訊，而Kafka訊息佇列的作用則是保證請求的順序以及資料的持久化和複製。

之所以會選擇Kafka，Tadas Vilkeliskis認為：

“RabbitMQ和ZeroMQ這樣的訊息系統要麼沒有如此高的寫能力，要麼需要犧牲永續性以便獲得更好的寫效能。資料庫也有類似的限制，它們通常都針對特定場景做了優化，但是這樣在其他的場景下就難有良好的表現。”

Tadas Vilkeliskis的話可能比較模糊，對於Kafka與其他的訊息佇列系統之間的比較，InfoQ之前也曾釋出過一篇文章《Apache Kafka：下一代分散式訊息系統》，其中就從生產和消費兩個方面對Kafka、Apache ActiveMQ V5.4和RabbitMQ V2.4的效能做了比較，結果是Kafka遙遙領先，或許這才是支撐Tadas Vilkeliskis使用Kafka的原因。

另外，Tadas Vilkeliskis還在這篇文章中分享了Kafka的資料分發機制，磁碟儲存空間的分配、訊息格式的處理、伺服器選擇以及資料壓縮等方面的內容，感興趣的讀者可以閱讀英文原文。

對於Tadas Vilkeliskis分享的方案，也有部分使用者提出了自己的想法，Ryan回覆說：

“這些都是不錯的效能資料。在VoltDB，我們發現有很多人在應對這種速度時會把資料從Kafka轉移到VoltDB上。VoltDB能夠處理這種速率的流量，同時能夠使用內建的輸出特性將其推動到下游系統。它可以在Kafka和最終的倉庫磁碟之間增加實時的資料抽取、轉換、載入、過濾、決策和分析的階段。”

“這是為了處理實時競價（RTB）麼？我也做了相似的事情，但是使用了完全不同的技術。我們的架構是基於NodeJS的，這種情況下我們清楚地知道請求來源於哪個地理位置。我們租用了高效能的專用伺服器（最少8核，有充足的RAM），有一個本地node叢集監聽“核心數量”的埠。然後在這之上有一個HAProxy負責同一臺機器埠間的負載均衡。在保持平均響應時間為1秒的情況下，我們的每一臺主機每秒鐘大約能夠處理14萬次請求。這是一個非常酷的專案，所有的事情都優化到了極致，同是我們還使用

ElasticSearch和Kibana實現了實時的分析和圖形化。”