消息隊列性能對比——ActiveMQ、RabbitMQ與ZeroMQ（譯文）

Dissecting Message Queues

概述：

　　我花了一些時間解剖各類庫執行分佈式消息。在這個分析中，我看了幾個不一樣的方面，包括API特性，易於部署和維護，以及性能質量.。消息隊列已經被分爲兩組：brokerless和brokered。

　　brokerless消息隊列是對等的，沒有中間商參與信息的傳遞，而brokered隊列有一些服務器端點之間。

 

性能分析的一些系統：　　

　　Brokerless
　　　　nanomsg
　　　　ZeroMQ

 

　　Brokered
　　　　ActiveMQ
　　　　NATS
　　　　Kafka
　　　　Kestrel
　　　　NSQ
　　　　RabbitMQ
　　　　Redis
　　　　ruby-nats

 

測試環境：

　　首先，讓咱們來看看性能指標，由於這能夠說是人們最關心的。我已經測量了兩個關鍵指標：吞吐量和延遲。

　　全部的測試都運行在一臺MacBook Pro 2.6 GHz的i7處理器，16GB內存。這些測試是評估一個單一的生產者和單一消費者的發佈訂閱拓撲結構。這提供了一個很好的基線。這將是有趣的基準縮放拓撲結構，但須要更多的儀器。

 

　　

 

開始測試：

　　　一、吞吐量基準：

　　　　吞吐量基準是指系統每秒可以處理消息的數量，須要注意的是隊列中可能有沒有單一的「吞吐量」。咱們在兩個不一樣的端點之間發送消息，因此咱們觀察到的是一個「發送方」吞吐量和一個「接收方」吞吐量，即每秒能夠發送的消息數和每秒能夠接收的消息數.。

　　　　 咱們此次測試經過發送1，000,000 個1kb 的消息而且計算兩邊發送和接收消息的時間，這裏面選擇1kb的數據是由於這種數據更加貼近咱們平常開發中遇到的消息請求，許多性能測試傾向於在100到500字節的範圍內使用較小的消息.，儘管每一個系統都是各不相同的，咱們只可以選取大致上類似的測試數據來進行測試。對於面向消息的中間件系統，只使用一個代理。

　　Brokeless：

　　

　　　　　　從圖片咱們能夠看出，在發送測有很高的吞吐量，然而有趣的是，發送者與接收者的比率差距。

　　　　　　ZeroMQ可以發送超過每秒5000000條消息/每秒但只能收到約600000 /秒。

　　　　　　相反，nanomsg發出害羞的3000000幀/秒可接待近2000000。

 

 

　　　Brokered：

　　

 

 

　　　　咱們能夠很直觀的觀察到，Brokered 消息隊列比Brokerless 少了至少兩個數量級以上的吞吐量。有一半的Brokered 消息隊列吞吐量少於25000條消息每秒。對於Redis的吞吐量或許有必定的誤導，儘管Redis 提供 發佈/訂閱 功能，它並非真正設計爲一個強大的消息隊列。以相似的方式使用ZeroMq，Redis切斷了慢用戶，重要的是要指出，這不是可以可靠地處理這種體積的消息。咱們能夠將他當作一個特殊點。Kafla 和 ruby-nats 和Redis 有類似的特色，可是可以可靠的處理間歇性故障信息。NATs 在這方面有着優越的吞吐量

 

　　　　經過上述的圖示分析，咱們能夠看到，Brokered 隊列在發送和接收兩方面有着一致的吞吐量，而不像Brokerless 那樣，發送方與接收方的吞吐量有着較大的差別。

 

　　　二、Latency Benchmarks 延遲基準

　　　　　　第二個關鍵性能指標是消息延遲，這就測量了在端點之間傳輸消息須要多長時間。直覺可能告訴咱們，這僅僅是吞吐量的逆，即若是吞吐量是消息/秒，延遲是秒/消息。然而，仔細看從ZeroMQ白皮書借這個形象，咱們能夠看到，這不是個案。

　　　　　　　　　　　　　　　　　　

　　　　　　現實狀況是，每一個消息發送的延遲線是不統一的，它能夠爲每個不一樣的。事實上，延遲和吞吐量之間的關係是有點涉及。

　　　　　　與吞吐量不一樣的是，延遲的測量並不區分發送方和接收方，而是做爲一個總體。可是，因爲每一個消息都有本身的延遲，咱們將看看他們的平均值。進一步，咱們將看到平均消息延遲與發送的消息數有關.。直覺告訴咱們，更多的信息意味着更多的排隊，這意味着更高的延遲。

　　　　　　下圖中：

　　　　　　　　藍色：nanomsg

　　　　　　　　紅色：ZeroMq

　　　　　　

　　　　　　　　　　　　　　　　　　　　

 

　　　　　　在通常狀況下，咱們的假設證實正確的，由於更多的消息被髮送到系統中，每一個消息的延遲增長。有趣的是，當咱們接近1000000條消息時，延遲出現的速度變慢了500000點.。另外一個有趣的觀察是在1000和5000之間的消息延遲的初始峯值，這是更加顯着nanomsg。這很難肯定因果關係，可是這些變化可能反映瞭如何在每一個庫中實現消息批處理和其餘網絡堆棧遍歷優化.。更多的數據點能夠提供更好的可視性。

　　　　　　

　　　　　　咱們看一下Brokered隊列和一些有趣的新的相似的模式。　　　　　　

　　　　　　ActiveMq

　　　　　　Kafka

　　　　　　RabbitMq　　　　

　　　　　　　　　　　　　　　　

　　　　他們的延遲數量級高於其餘的Brokered 延遲，所以他們ACtiveMq與RabbitMq分紅了本身AMQP範疇。

 

 

　　　　如今，咱們已經看到了一些關於這些不一樣的庫如何執行的經驗數據，我將看看他們如何從務實的角度來看工做。消息吞吐量和速度是很重要的，但若是庫很難使用、部署或維護，則不太實用.。

 

 

ZeroMQ and Nanomsg

　　　　從技術上講，nanomsg不是一個消息隊列，而是一個執行socket風格的圖書館分佈式消息經過各類便捷的方式。所以，除了在應用程序中嵌入庫自己以外，沒有什麼能夠部署的.。這使得部署一個非問題。

　　　　Nanomsg是一個由ZeroMQ的做者寫的，和我討論過，在對庫的工做以一個很是相似的方式。從發展的角度來看，nanomsg提供全面清潔的API。與ZeroMQ不一樣，認爲不存在一個上下文中，套接字綁定到。此外，nanomsg提供可插拔的運輸和通信協議，使其更加開放的延伸。其額外的內置可擴展性協議也使它至關有吸引力。

　　　　像ZeroMQ同樣，它保證消息將被原子性地傳遞完整和有序，但不保證它們的交付。局部的消息將沒法交付，而且部分消息可能沒法被交付。

　　　　ZeroMq 的研發者 Martin Sustrik：很清楚的指出：

　　　　　　Guaranteed delivery is a myth. Nothing is 100% guaranteed. That’s the nature of the world we live in. What we should do instead is to build an internet-like system that is resilient in face of failures and routes around damage.（保證交付是一個神話。沒有100％保證。這就是咱們生活的世界的性質。咱們應該作的是創建一個互聯網般的系統，面對失敗和路線損壞時彈性。）

 

ActiveMQ and RabbitMQ

　　　　ActiveMQ 和 RabbitMQ 都是AMQP 的一種具體實現。他們扮演着一個保證當心可以正常交付的角色。AcitveMQ 和 RabbitMQ 都支持 持久性或非持久性的信息交付。默認狀況下，消息會存儲到磁盤中，能夠保證消息隊列重啓時數據的一致，避免消息的丟失。它們還支持同步和異步發送消息，前者對延遲有實質性影響。爲了保證交付，這些代理使用消息確認，這也致使巨大的延遲代價。

　　　　就可用性和容錯性而言，這些代理經過共享存儲或無共享支持集羣。隊列能夠跨集羣節點進行復制，所以沒有單點故障或消息丟失。

　　　　AMQP是一個非平凡的協議，其創做者聲稱過分設計。這些額外的保證是以犧牲主要複雜性和性能折衷爲代價的。從根本上說，客戶更難實現和使用。

　　　　因爲它們是消息代理，ActiveMQ和RabbitMQ是須要在分佈式系統中管理的額外移動部件，這會帶來部署和維護成本。

Redis

　　最後是Redis。雖然Redis是輕量級消息和臨時存儲的理想選擇，但我不能主張將其用做分佈式消息傳遞系統的主幹。它的pub / sub很快，但它的功能有限。它須要大量的工做來創建一個健壯的系統。存在更好地適合於該問題的解決方案，諸如上面描述的那些解決方案，而且還存在一些縮放問題。

　　除此以外，Redis易於使用，易於部署和管理，而且佔用空間相對較小。根據用例，它能夠是一個偉大的選擇實時消息

 

 

附上原博文地址：http://bravenewgeek.com/dissecting-message-queues/