我已經閱讀了0MQ指南，并且了解了基本的套接字類型：PUSH/ PULL，REQ/ REP和PUB/ SUB。我對ROUTER/ DEALER和X-套接字（例如XSUB/ XPUB，XREQ/ XREP）感到非常困惑。這些套接字類型的用例是什么？
1 回答
眼眸繁星
TA貢獻1873條經驗 獲得超9個贊
瑣碎的原型
ZeroMQ“ 套接字 ”聽起來像是一個面向套接字的設備，但是仔細看，這個智能庫增加了一種形式化的通信模式（該模式使用了真正的套接字），該模式具有分層的設計以內部解決諸如內部彈性緩沖之類的細節。 ，內部1：N公平隊列發送/輪詢，內部ioThread負載平衡，僅舉幾例。
在這些內部智能子系統之上，又是基本的形式化通信模式-盡可能接近地命名，以類似于人類的行為-像（一個）- PUB拼寫+（其他）-- SUB抄寫-ZeroMQ 建立了“基礎最強大的消息傳遞方案的最低層”。
作為一個好幫手，而不是說一PUB- 插槽，一個可以選擇想象SUB，XPUB或者DEALER是相當的實體-與- “ 行為 ”，坐在電話線的一端，誰具有一定的硬連線的習慣，它可以在電話中使用。
因此，一些實體可以講一個到另一個，都PUB可以說給一個或多個SUB（S） -不知道有多少/如果有的話（是）連接到他的，好了，到任何他的電話線（是的，PUB可以有很多傳出的電話線-有關詳細信息，請檢查可用的ZeroMQ傳輸類，這些類PUB可以“暴露來電”或以其他方式部署-（哦，是的，甚至PUB可以“摘他的一條電話線”并撥打（ .connect（）朝向選定的SUB或XSUB對手方！酷...（是的，因為許多內置的ZeroMQ功能））-所有這些都是并行的。
SUB可以根據自己的判斷來決定并訂閱過濾器，從傳入的電話線上聽到或聽到不聽到的內容。自然地，其他一些人根本不具備預接線的能力，無法相互通電話并有意義地進行可行的對話，但可以與“友好”（行為兼容）的交易對手（a PAIR，例如，有一個唯一的機會去PAIR打電話+與另一個人說話- 伙伴）。
為了更深入地了解這些構建基塊（包括XPUB/ XSUB動機），為什么他們必須擴展普通PUB/ SUB原始，最好的建議方法是閱讀Pieter Hintjens的書“ Code Connected，Volume 1”（可下載pdf）。
（恕我直言，這是一本必讀的書，不僅涉及ZeroMQ本身的智能特性，而且還涉及思維方式和其他啟發性思想的轉變）。
ROUTER/ DEALER＆DEALER/ROUTER
這些形式的交流模式在圖37中得到了很好的說明，并在該書中進行了討論。值得一讀，而不是在這里說幾句話。
一ROUTER到DEALER示例（1對N的用例），其中一次服務器會談異步多個工人可以打開“倒掛”得到一個非常有用的N對1的架構，其中各種客戶交談，一臺服務器，并做這是異步的。因此，確切的用例由您的設計需求給出。
XPUB/ XSUB用例
一旦進入ZeroMQ基本元素之間的“ 中間媒介 ”連接模式，XPUB/ XSUB代理“設備”將提供一項附加服務，而不僅僅是作為.bind()＆的代理.connect()。它還“interpretes”的消息內容（檢查傳入zmq.SUBSCRIBE-s及接送“時間朝向真實PUB經由代理自己-lisher側XSUB通過讀?。?code>XPUB插座side.This是主要使用情況XSUB和XPUB
這樣，逐個掌握ZMQ武庫本身并不是目標。它是一種樂高風格的構建模塊套件，用于設計特定于項目的分布式消息傳遞模式，可以根據更復雜的需求進行協作-在單節點故障，性能可伸縮性，自適應重配置和許多其他功能之后進行自我修復其他。
復雜系統
典型的現實世界應用程序不僅要重用基本的PAIR/ PAIR，XREQ/ XREP，...基元，還需要走得更遠，在這些基元中適當地適合您的高層設計需求，并在上面添加行為策略，在您的全局設計控制下使用這些較低級別的原型。
為了安排代碼，值得首先花時間在本書上，而不是相反。
這將為您節省很多Aha！片刻之后。
- 1 回答
- 0 關注
- 642 瀏覽
添加回答
舉報
0/150
提交
取消