消息中間件主要實現的是異步、彈性消息以及隊列，彈性消息有時可以藉助於外存從而一定程度上可以實現峯值緩存，有效均衡服務器端壓力，同時消息可以進行一定程度上的定於，從而實現了基於分組的廣播，同時可以實現消息訂閱；
RPC則是主要集中於外部的方法調用，通過某種通訊方式實現數據的集中調用與訪問，以簡單通訊協議爲像本地方法一樣完成遠程方法調用；
ZeroMQ其實可以當成是一種互補的一種體現，首先定義通訊模式完成消息中間件中的訪問，同時在通訊的過程中可以進行相應的轉換，轉換目的比較明確，所以可以以i提高訪問的速度；
2、nanomsg裏關於ZerocMQ的缺陷
在傳輸協議上，nanomsg構建了用於新傳輸協議的api，從而使用戶不需要再囿於某種特定的傳輸協議，同時可以按照自己的實際需求動態插拔協議，從而使應用場景更加靈活；
在兼容性方面，現在實現了POSIX的完全兼容，同時API本身也從一定程度上帶來簡化；
nanomsg是縣城安全的，與之對應，這也是ZerocMQ無法改變，ZeroMQ每個對象都被隔離自己的線程，並且通過消息進行傳輸，然而套接字的傳輸並非線程安全地；
nanomsg使用基數樹的方式存儲訂閱關係，而並非想ZeroMQ一樣建立trie結構，所以不需要進行拷貝，同時在拷貝過程中支持RDMA；
在調度方法方面ZeroMQ使用輪換，然而取法路徑的感知，所以導致訪問效率上可能會打一些折扣；
同時nanomsg提供了nanocat工具進行系統交互；
3、假如開發一個高吞吐的訂單服務，需要手機端、網頁端、以及其他第三方接口調用，爲了保證高吞吐，如何用RPC+消息隊列方式來實現首先，項目的設計必須基於業務，首先需要將對業務進行分類，並且分析出業務可能存在的交互點，分析出那些業務的實時性比較高，那些業務並非需要實時計算；
其次，在進行訂單提交的過程中可以一定程度上進行一定延時受理，即首先樂觀地認爲訂單是全部受理的然後在後端構建一個分佈式的訂單處理隊列，對用戶提交訂單進行受理；
再次，如果想增強體驗的話可以在訂單提交過程中同時使用RPC保持一個持久連接，在用戶訂單有一定效果的的時候給用戶一定反饋；
最後，在進行訪問的過程中需要在調用過程中注意一定的安全認證機制，必要時使用簡化token方式進行交互，而類似於這樣的業務可以使用rpc直接進行調用；