消息隊列的選擇：kafka、rabbitmq、zeromq

最近在作一個數據分析相關的工做，需求是將全國各地idc內的流量信息進行彙總和分析最後吐出一些安全策略，因爲對時效性的要求比較高，大概每隔幾秒就會有一次幾十M的的數據須要傳遞到彙總服務器上去，並且隨着業務的發展數據量還會愈來愈大，因此使用什麼手段來作數據的傳輸就成爲了一個關鍵的問題。

首先是可擴展性，若是使用標準socket進行傳遞的話隨着數據量的擴大單點確定會成爲瓶頸，並且若是可用性要高的話，異步、緩存、重傳等等都是須要考慮的要素，爲了開速上線功能就要去幾個開源的消息隊列裏挑選一下合適這個項目的了。

因爲團隊內的一些推薦和本身之前的經驗，初步定下了kafka、rabbitmq、zeromq三個軟件，這裏主要介紹一下這三個軟件各自的特色和功能，詳細的使用說明和學習資料後面在補。

1、rabbitmq

首先是百科裏的一段話，Rabbitmq是流行的開源消息隊列系統，使用erlang語言進行開發。RabbitMQ是AMQP(高級消息隊列協議)的標準實現。能夠說從功能上rabbitmq基本上是符號此次項目要求的工具。

它的優勢有：

一、完整的消息隊列系統，支持多種消息隊列模式，包括競爭消費；

二、基於AMQP

三、支持集羣模式，擴展集羣容量和性能比較方便，同時集成了集羣的監控和管理；

四、支持消息的持久化；

缺點是：

一、須要學習比較複雜的接口和協議，比較耗費時間；

二、性能不是特別理想大概在1wqps左右；

三、使用Erlang語言，之前沒據說過，出了問題不會排查；

2、zeromq

之前常常在內網中使用，號稱是最快的消息隊列，因爲它支持的模式很是多：tcp、ipc、inproc、multicas，基本已經達到了替代標準socket的地步了，據說linux內核已經準備將zeromq歸入標準內核中了。

zeromq是一個智能傳輸層，它並非對socket的封裝，而是在其之上有一套本身的協議，可使用很是豐富的開發模式像扇出(fanout)、發佈訂閱(pub-sub)、任務分發(task distribution)、請求響應(request-reply)等。

優勢：

一、缺省爲異步I/O交互，封裝了鏈接的維護操做，消息處理並行化；

二、性能很是不錯；

三、編程簡單，上手很快；

缺點：

一、消息沒法持久化，除非本身在實現一箇中間件，不然消息傳遞完成就刪除了；

二、擴展性不是很好，實際上是一個消息庫，並不算是MQ；

3、kafka

日誌團隊正在使用的工具，是一個消息發佈訂閱系統。生產者向某個隊列發送一個數據，消費者訂閱一個隊列，一旦這個隊列內產生新的數據了，中間人就會將數據發送給全部訂閱隊列的消費者。

用術語來講生產者就是producer、消費者就是consumer、中間人就是broker，kafka主要就是這三者之間進行聯繫的。

優勢：

一、高吞吐量率，每秒能處理幾十萬條消息；

二、分佈式架構，可以以集羣進行處理；

三、日誌團隊已經創建了kafka集羣，能夠蹭一蹭；

缺點：

一、之前沒有使用過，須要必定的熟悉時間，和開發工做；

4、結論

日誌團隊的強烈推薦，和強大的技術支持，最後決定使用kafka了，它提供的特色和優點確實也令人心動，不過此次的調研也讓我瞭解了一些開源軟件的設計思路和軟件選擇的見解，後面在寫幾篇記錄一下。