zmq是什麼？
這是個類似於socket的一系列介面，他跟socket的區別是：普通 的socket是端到端的（1:1的關係），而zmq卻是可以n：m 的關係，人們對bsd套接字的了解較多的是點對點的連線，點對點連線需要顯式地建立連線、銷毀連線、選擇協議（tcp/udp）和處理錯誤等，而zmq屏 蔽了這些細節，讓你的網路程式設計更為簡單。zmq用於node與node間的通訊，node可以是主機或者是程序。
引用官方的說法： 「zmq(以下zeromq簡稱zmq)是乙個簡單好用的傳輸層，像框架一樣的乙個socket library，他使得socket程式設計更加簡單、簡潔和效能更高。是乙個訊息處理佇列庫，可在多個執行緒、核心和主機盒之間彈性伸縮。zmq的明確目標是 「成為標準網路協議棧的一部分，之後進入linux核心」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」bsd套接 字之上的一 層封裝。zmq讓編寫高效能網路應用程式極為簡單和有趣。」
接下來是來說說zmq有模式，可以歸納成三種，請求回應模式（1對n），發布訂閱模式(單向1對n)，還有推拉模型。
1：請求回應模式（req-rep）
可以有多個client，這個很容易理解跟tcp很像，但伺服器與客戶端必須是1問1答的形式。直接看源**。
#include #include執行結果：#include
#include
#include
using
namespace
std;
dword winapi mythread_client(lpvoid lpparamter)
return0;
}dword winapi mythread_client1(lpvoid lpparamter)
return0;
}dword winapi mythread_servce(lpvoid lpparamter)
}int
main ()
這裡我建立了兩個客戶端和乙個伺服器，每個都獨立執行乙個執行緒。客戶端1發了「hello」，客戶端2發了「sb」，伺服器都能接收到並且返回了world。
2：發布訂閱模式（pub-sub)
所謂發布訂閱，比如天氣預報，當很多人訂閱之後，中心伺服器直接往訂閱的人傳送就可以了，不需要管對方有沒有收到。也就是1對n的模式。這裡還有重要的乙個概念，頻道：跟收音機的頻道類似，訂閱者設定了頻道才能聽到該頻道的訊息
看例程式：
#include #include結果：#include
#include
#include
using
namespace
std;
//訂閱1
dword winapi mythread_sub1(lpvoid lpparamter)
return0;
}//訂閱2dword winapi mythread_sub2(lpvoid lpparamter)
return0;
}//訂閱3dword winapi mythread_sub3(lpvoid lpparamter)
return0;
}//發布執行緒
dword winapi mythread_pub(lpvoid lpparamter)
}int
main ()
例程中，設定了1個發布端和3個訂閱端，訂閱端訂閱的頻道分別是是a,b和沒有訂閱，發布端發布了對應頻道的訂閱訊息。由此訂閱3沒有設定頻道，所以收不到訊息。
3：推拉模式，這個詞語感覺汙，還是我想歪了。還沒研究過，不過看網上說的，跟發布訂閱模式類似，只是可以負載均衡。目前專案中也沒有用到，下次有機會再研究吧。
zeromq官網的github上面有詳細的例程：
訊息佇列之訊息過濾
眾所周知，rocketmq是支援訊息過濾的，即傳送訊息時，可以給訊息設定乙個tag。訂閱主題的時候，可以設定只消費攜帶某些tag的訊息，起到訊息過濾的作用。rocketmq中是把訊息tag通過雜湊轉換成了的long型，儲存在了訊息索引中。在訂閱客戶端拉取訊息時，為了減少協議大小，減低報文長度，拉取協...
Linux IPC 之訊息佇列
system v or posix 該使用哪個呢，這是個問題 相對而言，我更傾向於後者 posix mq posix mq 的概況看這裡 man mq overview 簡單的實現 include include include include define my mq name my test m...
linux IPC之訊息佇列
訊息佇列就是乙個訊息的鍊錶。可以把訊息看作乙個記錄，具有特定的格式以及特定的優先順序。對訊息佇列有寫許可權的程序可以向其中按照一定的規則新增新訊息 對訊息佇列有讀許可權的程序則可以從訊息佇列中讀走訊息。在linux系統中訊息佇列與鍵值一一對應。訊息佇列是通過鍊錶管理的，核心提供乙個struct ms...