消息隊列現在是模塊之間通信的非常通用的解決方案了。消息隊列使得進程間的通信可以跨越物理機，這對於分佈式系統尤爲重要，畢竟我們不能假定進程究竟是部署在同一臺物理機上還是部署到不同的物理機上。RabbitMQ是應用比較廣泛的MQ
提到MQ，不得不提的是ZeroMQ。ZeroMQ封裝了Socket，引用官方的說法： “ZMQ (以下 ZeroMQ 簡稱 ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個 socket library，他使得 Socket 編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ 的明確目標是“成爲標準網絡協議棧的一部分，之後進入 Linux 內核”。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的“傳統”BSD 套接字之上的一層封裝。ZMQ 讓編寫高性能網絡應用程序極爲簡單和有趣。”
因此, ZeroMQ不是傳統意義上的MQ。它比較適用於節點之間和節點與Master之間的通信。Storm在0.8之前的Worker之間的通信就是通過ZeroMQ。但是爲什麼0.9就是用Netty替代了ZeroMQ呢？說替代不大合適，只是0.9的默認的Worker之間的通信是使用了Netty，ZeroMQ還是支持的。Storm官方認爲ZeroMQ有以下缺點：
- 不容易部署，尤其是在雲環境下：以爲ZMQ是以Ｃ寫的，因此它還是緊依賴於操作系統環境的。
- 無法限制其內存。通過JVM可以很容易的限制java所佔用的內存。但是ZMQ對於Storm來說是個黑盒似得存在。
- Storm無法從ZMQ獲取信息。比如Storm無法知道當前buffer中有多少數據爲發送。
當然了還有所謂的性能問題，具體可以訪問Netty作者的blog。結論就是Netty的性能比ZMQ（在默認配置下）好兩倍。不知道所謂的ZMQ的默認配置是什麼。反正我對這個結果挺驚訝。當然了，Netty使用Java實現的確方便了在Worker之間的通信加上授權和認證機制。這個使用ZMQ的確是不太好做。
