NetMQ（一）：zeromq簡介

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：仍然是自由軟件！