ZeroMQ系列 之NetMQ
一：zeromq簡介
二：NetMQ 請求響應模式 Request-Reply
三：NetMQ 發布訂閱模式 Publisher-Subscriber
四：NetMQ 推拉模式 Push-Pull
zeromq簡介
NetMQ 是 ZeroMQ的C#移植版本。
1：zeromq是什么
NetMQ （ZeroMQ to .Net），ZMQ號稱史上最快中間件。
它對socket通信進行了封裝，使得我們不需要寫socket函數調用就能完成復雜的網絡通信。
它跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N:M的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網絡編程更為簡單。
它是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。和一般意義上的消息隊列產品不同的是，它沒有消息隊列服務器，而更像是一個網絡通信庫。從網絡通信的角度看，它處於會話層之上，應用層之下，屬於傳輸層。
2：zeromq的消息模型
zeromq將消息通信分為4種模型，分別是一對一結對模型（Exclusive-Pair）、請求回應模型（Request-Reply）、發布訂閱模型（Publish-Subscribe）、推拉模型（Push-Pull）。這4種模型總結出了通用的網絡通信模型，在實際中可以根據應用需要，組合其中的2種或多種模型來形成自己的解決方案。
2.1 一對一結對模型 Exclusive-Pair
最簡單的1:1消息通信模型，用來支持傳統的 TCP socket 模型,主要用於進程內部線程間通信。可以認為是一個TCP Connection，但是TCP Server只能接受一個連接。采用了lock free實現，速度很快。數據可以雙向流動，這點不同於后面的請求響應模型。(不推薦使用，沒有例子）
2.2 請求回應模型 Request-Reply
由請求端發起請求，然后等待回應端應答。一個請求必須對應一個回應，從請求端的角度來看是發-收配對，從回應端的角度是收-發對。跟一對一結對模型的區別在於請求端可以是1~N個。
請求端和回應端都可以是1：N的模型。通常把1認為是server,N認為是Client。ZeroMQ可以很好的支持路由功能（實現路由功能的組件叫作Device),把1：N擴展為N:M(只需要加入若干路由節點）。從這個模型看，更底層的端點地址是對上層隱藏的。每個請求都隱含有回應地址，而應用則不關心它。通常把該模型主要用於遠程調用及任務分配等。
(NetMQ請求響應C#調用案例)
2.3 發布訂閱模型 Publisher-Subscriber
發布端單向分發數據，且不關心是否把全部信息發送給訂閱端。如果發布端開始發布信息時，訂閱端尚未連接上來，則這些信息會被直接丟棄。訂閱端未連接導致信息丟失的問題，可以通過與請求回應模型組合來解決。訂閱端只負責接收，而不能反饋，且在訂閱端消費速度慢於發布端的情況下，會在訂閱端堆積數據。該模型主要用於數據分發。天氣預報、微博明星粉絲可以應用這種經典模型。 (NetMQ發布訂閱模式C#調用案例)
2.4 推拉模型 Push-Pull
Server端作為Push端，而Client端作為Pull端，如果有多個Client端同時連接到Server端，則Server端會在內部做一個負載均衡，采用平均分配的算法，將所有消息均衡發布到Client端上。與發布訂閱模型相比，推拉模型在沒有消費者的情況下，發布的消息不會被消耗掉；在消費者能力不夠的情況下，能夠提供多消費者並行消費解決方案。該模型主要用於多任務並行。
(NetMQ推拉模式C#調用案例)
3：zeromq的優勢
- TCP：ZeroMQ基於消息，消息模式，而非字節流。
- XMPP：ZeroMQ更簡單、快速、更底層。Jabber可建在ZeroMQ之上。
- AMQP：完成相同的工作，ZeroMQ要快100倍，而且不需要代理（規范更簡潔——少278頁）
- IPC：ZeroMQ可以跨多個主機盒，而非單台機器。
- CORBA：ZeroMQ不會將復雜到恐怖的消息格式強加於你。
- RPC：ZeroMQ完全是異步的，你可以隨時增加/刪除參與者。
- RFC 1149：ZeroMQ比它快多了！
- 29west LBM：ZeroMQ是自由軟件！
- IBM低延遲：ZeroMQ是自由軟件！
- Tibco：仍然是自由軟件！