zeromq使用模式实验总结

zeromq:官网 安装  demo及各语言绑定 golang绑定

实验环境:win10 x64/centos6 x86 zeromq4.0.6

zmq三种模式:push/pull、pub/sub、req/resp

一、push/pull模式:

zeromq使用模式实验总结

A程序PUSH代码如下:

import zmq
import time
context = zmq.Context() sender = context.socket(zmq.PUSH)
sender.bind("tcp://*:5557") for task_nbr in range(): workload = 'task2---'+str(task_nbr)
sender.send_string(u'%s' % workload)
time.sleep(0.1)

B程序PULL代码如下:

import time
import zmq context = zmq.Context() receiver = context.socket(zmq.PULL)
receiver.connect("tcp://localhost:5557") while True: s = receiver.recv()
time.sleep()

A程序准备发送1000个task任务,完事退出;B程序一直pull。

A先启动,此时push会一直阻塞,直到有一个pull连接,task才发出,假如中途B挂掉,A也继续进入阻塞,B再次上线,pull开始从上次A阻塞时的任务拉取。假如A挂掉,task任务发送中断,则B一直pull到A挂前发出的任务为止,这时候A再重启上线,则是另一回事了,任务for循环又重新开始,B继续。

B先启动,A后启动,场景和以上A先启动一样。

push一端具有负载均衡功能,pull一端可以多启动几个实例,均衡执行task,若中途pull一端挂掉,则push自动把任务分发到其他pull上。

二、 pub/sub模式

zeromq使用模式实验总结

A程序代码如下:

pub_Queue = Queue.Queue()
context = zmq.Context()
publisher = context.socket(zmq.PUB)
publisher.bind("tcp://*:5557") while True:
publisher.send_string(msg)

BCD代码如下:

 context    = zmq.Context()
subscriber = context.socket(zmq.SUB)
subscriber.connect("tcp://*:5557")
subscriber.setsockopt(zmq.SUBSCRIBE, "") while True: contents = subscriber.recv()
print("%s" % contents)

A pub端通过sub端subscriber.setsockopt(zmq.SUBSCRIBE, "2")的“2”过滤信息,sub端可以订阅多个。远程公网使用该模式,需要pub端定期维持心跳包,比如半分钟pub一条信息。

三、req/resp模式

zeromq使用模式实验总结

A程序代码如下:

import zmq

context = zmq.Context()

socket = context.socket(zmq.REQ)
socket.connect("tcp://localhost:5555") for request in range():
socket.send(b"Hello") message = socket.recv()
print "Received reply %s [ %s ]" % (request, message)

B程序代码如下:

import time
import zmq context = zmq.Context()
socket = context.socket(zmq.REP)
socket.bind("tcp://*:5555") while True:
message = socket.recv() time.sleep() socket.send(b"World")

可以没有先后启动顺序,假如A先启动,阻塞;假如B先启动,等待请求接入。

过程中,假如A挂掉,再启动,可以继续请求应答;而假如时B服务端挂掉再重启,则A客户端已经连不上了,阻塞。情形和以上几种模式一样的。

总结:

以上是通过官网python bind的源码做的实验。虽然不要求客户端/服务端的先后启动次序,但是中途若是服务端挂掉再启动,就是另一种情况了。在表现形式上来说,似乎此时的c/s线路不再是挂掉之前的,而是服务端又启动了一条线路一样。这个时候,就需要客户端去检测判断服务端状态,以确定重连机制。到底是不是这样呢?需要深入zeromq的代码一看究竟了!

上一篇:C#中保留两位小数但不四舍五入的最优做法


下一篇:mysql数据库常用语句3