詳解Python 實(shí)現(xiàn) ZeroMQ 的三種基本工作模式
簡(jiǎn)介
引用官方說(shuō)法:ZMQ(以下 ZeroMQ 簡(jiǎn)稱 ZMQ)是一個(gè)簡(jiǎn)單好用的傳輸層,像框架一樣的一個(gè) socket library,他使得 Socket 編程更加簡(jiǎn)單、簡(jiǎn)潔和性能更高。
是一個(gè)消息處理隊(duì)列庫(kù),可在多個(gè)線程、內(nèi)核和主機(jī)盒之間彈性伸縮。
ZMQ 的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分,之后進(jìn)入 Linux 內(nèi)核”。現(xiàn)在還未看到它們的成功。但是,它無(wú)疑是極具前景的、并且是人們更加需要的“傳統(tǒng)” BSD 套接字之上的一 層封裝。ZMQ 讓編寫(xiě)高性能網(wǎng)絡(luò)應(yīng)用程序極為簡(jiǎn)單和有趣。
它跟 RabbitMQ,ActiveMQ 之類有著相當(dāng)本質(zhì)的區(qū)別,ZeroMQ 根本就不是一個(gè)消息隊(duì)列服務(wù)器,更像是一組底層網(wǎng)絡(luò)通訊庫(kù),對(duì)原有的 Socket API 加上一層封裝,使我們操作更簡(jiǎn)便。
三種工作模式
Request-Reply 模式:
說(shuō)到“請(qǐng)求-應(yīng)答”模式,不得不說(shuō)的就是它的消息流動(dòng)模型。消息流動(dòng)模型指的是該模式下,必須嚴(yán)格遵守“一問(wèn)一答”的方式。
發(fā)出消息后,若沒(méi)有收到回復(fù),再發(fā)出第二條消息時(shí)就會(huì)拋出異常。同樣的,對(duì)于 Rep 也是,在沒(méi)有接收到消息前,不允許發(fā)出消息。
基于此構(gòu)成“一問(wèn)一答”的響應(yīng)模式。
server:
# -*- coding=utf-8 -*- import zmq context = zmq.Context() socket = context.socket(zmq.REP) socket.bind("tcp://*:5555") while True: message = socket.recv() print("Received: %s" % message) socket.send("I am OK!")
client:
# -*- coding=utf-8 -*- import zmq context = zmq.Context() socket = context.socket(zmq.REQ) socket.connect("tcp://localhost:5555") socket.send('Are you OK?') response = socket.recv() print("response: %s" % response)
Publish-Subscribe 模式:
“發(fā)布-訂閱”模式下,“發(fā)布者”綁定一個(gè)指定的地址,例如“192.168.10.1:5500”,“訂閱者”連接到該地址。該模式下消息流是單向的,只允許從“發(fā)布者”流向“訂閱者”。且“發(fā)布者”只管發(fā)消息,不理會(huì)是否存在“訂閱者”。一個(gè)“發(fā)布者”可以擁有多個(gè)訂閱者,同樣的,一個(gè)“訂閱者”也可訂閱多個(gè)發(fā)布者。
雖然我們知道“發(fā)布者”在發(fā)送消息時(shí)是不關(guān)心“訂閱者”的存在于否,所以先啟動(dòng)“發(fā)布者”,再啟動(dòng)“訂閱者”是很容易導(dǎo)致部分消息丟失的。那么可能會(huì)提出一個(gè)說(shuō)法“我先啟動(dòng)‘訂閱者',再啟動(dòng)‘發(fā)布者',就能解決這個(gè)問(wèn)題了?”
對(duì)于 ZeroMQ 而言,這種做法也并不能保證 100% 的可靠性。在 ZeroMQ 領(lǐng)域中,有一個(gè)叫做“慢木匠”的術(shù)語(yǔ),就是說(shuō)即使我是先啟動(dòng)了“訂閱者”,再啟動(dòng)“發(fā)布者”,“訂閱者”總是會(huì)丟失第一批數(shù)據(jù)。因?yàn)樵凇坝嗛喺摺迸c端點(diǎn)建立 TCP 連接時(shí),會(huì)包含幾毫秒的握手時(shí)間,雖然時(shí)間短,但是是存在的。再加上 ZeroMQ 后臺(tái) IO 是以一部方式執(zhí)行的,所以若不在雙方之間施加同步策略,消息丟失是不可避免的。
關(guān)于“發(fā)布-訂閱”模式在 ZeroMQ 中的一些其他特點(diǎn):
- 公平排隊(duì),一個(gè)“訂閱者”連接到多個(gè)發(fā)布者時(shí),會(huì)均衡的從每個(gè)“發(fā)布者”讀取消息,不會(huì)出現(xiàn)一個(gè)“發(fā)布者”淹沒(méi)其他“發(fā)布者”的情況。
- ZMQ3.0 以上的版本,過(guò)濾規(guī)則發(fā)生在“發(fā)布方”。 ZMQ3.0 以下的版本,過(guò)濾規(guī)則發(fā)生在“訂閱方”。其實(shí)也就是處理消息的位置。
server:
# -*- coding=utf-8 -*- import zmq import time context = zmq.Context() socket = context.socket(zmq.PUB) socket.bind("tcp://*:5555") for i in range(10): print('send message...' + str(i)) socket.send('message' + str(i)) time.sleep(1)
client:
# -*- coding=utf-8 -*- import zmq context = zmq.Context() socket = context.socket(zmq.SUB) socket.connect("tcp://localhost:5555") socket.setsockopt(zmq.SUBSCRIBE, '') while True: response = socket.recv() print("response: %s" % response)
Parallel Pipeline 模式:
在說(shuō)明“管道模式”前,需要明確的是在 ZeroMQ 中并沒(méi)有絕對(duì)的服務(wù)端與客戶端之分,所有的數(shù)據(jù)接收與發(fā)送都是以連接為單位的,只區(qū)分 ZeroMQ 定義的類型。就像套接字綁定地址時(shí),可以使用 bind ,也可以使用 connect ,只是通常我們將理解中的服務(wù)端 bind 到一個(gè)地址,而理解中的客戶端 connec 到該地址。
“管道模式”一般用于任務(wù)分發(fā)與結(jié)果收集,由一個(gè)任務(wù)發(fā)生器來(lái)產(chǎn)生任務(wù),“公平”的派發(fā)到其管轄下的所有 worker,完成后再由結(jié)果收集器來(lái)回收任務(wù)的執(zhí)行結(jié)果。
整體流程比較好理解,worker 連接到任務(wù)發(fā)生器上,等待任務(wù)的產(chǎn)生,完成后將結(jié)果發(fā)送至結(jié)果收集器。如果要以客戶端服務(wù)端的概念來(lái)區(qū)分,這里的任務(wù)發(fā)生器與結(jié)果收集器是服務(wù)端,而 worker 是客戶端。
前面說(shuō)到了這里任務(wù)的派發(fā)是“公平的”,因?yàn)閮?nèi)部采用了 LRU 的算法來(lái)找到最近最久未工作的閑置 worker。但是公平在這里是相對(duì)的,當(dāng)任務(wù)發(fā)生器啟動(dòng)后,第一個(gè)連接到它的 worker 會(huì)在一瞬間承受整個(gè)任務(wù)發(fā)生器產(chǎn)生的 tasks。
總結(jié)來(lái)說(shuō)由三部分組成,push 進(jìn)行數(shù)據(jù)推送,work 進(jìn)行數(shù)據(jù)緩存,pull 進(jìn)行數(shù)據(jù)競(jìng)爭(zhēng)獲取處理。區(qū)別于 Publish-Subscribe 存在一個(gè)數(shù)據(jù)緩存和處理負(fù)載。
當(dāng)連接被斷開(kāi),數(shù)據(jù)不會(huì)丟失,重連后數(shù)據(jù)繼續(xù)發(fā)送到對(duì)端。
server:
# -*- coding=utf-8 -*- import zmq import time context = zmq.Context() socket = context.socket(zmq.PUSH) socket.bind("tcp://*:5557") for i in range(10): socket.send('message' + str(i)) # 沒(méi)啟 worker 時(shí)不會(huì)發(fā)消息 print('send message...' + str(i)) time.sleep(1)
work:
# -*- coding=utf-8 -*- import zmq context = zmq.Context() receive = context.socket(zmq.PULL) receive.connect('tcp://127.0.0.1:5557') sender = context.socket(zmq.PUSH) sender.connect('tcp://127.0.0.1:5558') while True: data = receive.recv() print('transform...' + data) sender.send(data)
client:
# -*- coding=utf-8 -*- import zmq context = zmq.Context() socket = context.socket(zmq.PULL) socket.bind("tcp://*:5558") while True: response = socket.recv() print("response: %s" % response)
以上。
參考文檔:
http://www.dbjr.com.cn/article/177043.htm
總結(jié)
到此這篇關(guān)于詳解Python 實(shí)現(xiàn) ZeroMQ 的三種基本工作模式的文章就介紹到這了,更多相關(guān)python ZeroMQ工作模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
vscode搭建之python?Django環(huán)境配置方式
這篇文章主要介紹了vscode搭建之python?Django環(huán)境配置方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-01-01python [:3] 實(shí)現(xiàn)提取數(shù)組中的數(shù)
今天小編就為大家分享一篇python [:3] 實(shí)現(xiàn)提取數(shù)組中的數(shù),具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2019-11-11Python調(diào)用ChatGPT的API實(shí)現(xiàn)文章生成
最近ChatGPT大火,在3.5版本后開(kāi)放了接口API,所以很多人開(kāi)始進(jìn)行實(shí)操,這里我就用python來(lái)為大家實(shí)現(xiàn)一下,如何調(diào)用API并提問(wèn)返回文章的說(shuō)明2023-03-03Python數(shù)據(jù)分析23種Pandas核心操作方法總結(jié)
在本文中,作者從基本數(shù)據(jù)集讀寫(xiě)、數(shù)據(jù)處理和?DataFrame?操作三個(gè)角度展示了?23?個(gè)?Pandas?核心方法,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-05-05Python數(shù)據(jù)結(jié)構(gòu)與算法之圖的最短路徑(Dijkstra算法)完整實(shí)例
這篇文章主要介紹了Python數(shù)據(jù)結(jié)構(gòu)與算法之圖的最短路徑(Dijkstra算法),結(jié)合完整實(shí)例形式分析了Python圖的最短路徑算法相關(guān)原理與實(shí)現(xiàn)技巧,需要的朋友可以參考下2017-12-12Python爬蟲(chóng)之超級(jí)鷹驗(yàn)證碼應(yīng)用
眾所周知python是一個(gè)很強(qiáng)大的語(yǔ)言,它擁有眾多的庫(kù),今天我嘗試了使用超級(jí)鷹第三方平臺(tái)進(jìn)行驗(yàn)證碼的開(kāi)發(fā),需要的朋友可以參考下2022-08-08python實(shí)現(xiàn)統(tǒng)計(jì)代碼行數(shù)的方法
這篇文章主要介紹了python實(shí)現(xiàn)統(tǒng)計(jì)代碼行數(shù)的方法,涉及Python中os模塊及codecs模塊的相關(guān)使用技巧,需要的朋友可以參考下2015-05-05Python獲取任意xml節(jié)點(diǎn)值的方法
這篇文章主要介紹了Python獲取任意xml節(jié)點(diǎn)值的方法,涉及Python操作XML節(jié)點(diǎn)的相關(guān)技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2015-05-05