ZeroMQ/ZMQ推/拉模式的实用性

Question

在试验ZeroMQ Push/Pull(他们称之为Pipeline)套接字类型时,我很难理解这种模式的效用.它被称为"负载平衡器".

如果单个服务器向多个工作人员发送任务,推/拉将在所有客户端之间均匀地分发任务.3个客户端和30个任务,每个客户端获得10个任务:client1获取任务1,4,7,... client2,2,5,...等等.很公平.从字面上看.

但是,在实践中,通常存在任务复杂性或客户端计算资源(或可用性)的非同类混合,然后这种模式严重破坏.所有任务似乎都是事先安排好的,服务器不了解客户端的进度或者是否可用.如果client1发生故障,其余的任务不会发送到其他客户端,但仍会为client1排队.如果client1保持关闭状态,则永远不会处理这些任务.相反,如果客户端处理其任务的速度更快,则它不会获得进一步的任务并保持空闲状态,因为它们仍然安排在其他客户端上.

使用REQ/REP是一种可能的解决方案 然后,任务仅被提供给可用资源.

我错过了什么吗？如何Push/Pull有效地使用？有没有办法用这种套接字类型来处理客户端,任务等的不对称性？

谢谢!

这是一个简单的Python示例:

# server

import zmq
import time

context = zmq.Context()
socket = context.socket(zmq.PUSH)
#socket = context.socket(zmq.REP)   # uncomment for Req/Rep

socket.bind("tcp://127.0.0.1:5555")

i = 0
time.sleep(1)   # naive wait for clients to arrive

while True:
  #msg = socket.recv()    # uncomment for Req/Rep
  socket.send(chr(i))
  i += 1 
  if i == 100:
    break

time.sleep(10)   # naive wait for tasks to drain

.

# client

import zmq
import time
import sys

context = zmq.Context()

socket = context.socket(zmq.PULL)
#socket = context.socket(zmq.REQ)    # uncomment for Req/Rep

socket.connect("tcp://127.0.0.1:5555")

delay = float(sys.argv[1])

while True:
  #socket.send('')     # uncomment for Req/Rep
  message = socket.recv()
  print "recv:", ord(message)
  time.sleep(delay)

在命令行(即1,1和0.1)上使用延迟参数启动3个客户端,然后在服务器上启动,并查看所有任务是如何均匀分布的.然后杀死其中一个客户端以查看其剩余的任务未得到处理.

取消注释指示的行以将其切换到Req/Rep类型套接字并观察更有效的负载平衡器.

Answer 1

它不是一个负载均衡器,这是一个错误的解释,暂时停留在0MQ文档中.要进行负载平衡,您必须从工作人员那里获得有关其可用性的一些信息.与DEALER一样,PUSH是一个循环经销商.它的原始速度和简单性非常有用.您不需要任何类型的喋喋不休,只需将管道任务抽到管道中,并且可以像网络一样快速地将它们喷射到所有可用的工作人员.

当您执行大量小任务以及工作人员不经常来去时,该模式非常有用.该模式不适合需要时间来完成的较大任务,因为您需要一个仅向可用工作人员发送新任务的队列.它也会受到反模式的影响,如果客户端发送许多任务然后工作人员连接,第一个工作人员将获取1,000条左右的消息,而其他人仍在忙着连接.

您可以通过多种方式创建自己的高级路由.查看指南中的LRU模式:工人明确告诉经纪人'准备好'.您还可以执行基于信用的流量控制,这就是我在任何实际负载平衡情况下所做的事情.这是LRU模式的概括.见http://hintjens.com/blog:15