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

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

1 个答案: