在ZMQ Streamer设备上控制流的最佳实践？

Question

想象一下，我有一个波纹管模板中的流媒体设备。

来自here的图片

def worker(backend_port):
    context = zmq.Context()
    socket = context.socket(zmq.PULL)
    socket.connect("tcp://127.0.0.1:%d" % backend_port)
    while True:
        task = socket.recv()
        # do something

def streamer(frontend_port):# it's called streamer because streams files from hdfs
    context = zmq.Context()
    socket = context.socket(zmq.PUSH)
    socket.connect("tcp://127.0.0.1:%d" % frontend_port)
    while True:
        #  get the file
        #  prepare it
        socket.send(msg, copy=False)

number_of_workers = 16
number_streamers = 10

frontend_port = 7559
backend_port = 7560

streamerdevice  = ProcessDevice(zmq.STREAMER, zmq.PULL, zmq.PUSH)
streamerdevice.bind_in("tcp://127.0.0.1:%d" % frontend_port )
streamerdevice.bind_out("tcp://127.0.0.1:%d" % backend_port)
streamerdevice.setsockopt_in(zmq.IDENTITY, b'PULL')
streamerdevice.setsockopt_out(zmq.IDENTITY, b'PUSH')
streamerdevice.start()

for i in range(number_of_workers):
    p = Process(target=yolo, args=(backend_port,))
    p.start()

for i in range(number_streamers):
    s = Process(target=streamer, args=(frontend_port,))
    s.start()

要提供更多信息，消息是图像，因此尺寸较大。我正在使用零副本。在我的案例中，性能是最重要的一点，因为我的规模很大。

• 是否可以对streamerdevice进行多线程处理？

• 如何控制流量？有没有办法知道有多少邮件正在等待处理？

• 主要目标之一是使工作人员的接收时间尽可能快。有什么建议吗？

• 在zmq.Context(nIoTHREADs)端启动nIoTHREADs> 1的worker有帮助吗？

---

Answer 1

  

如何运行多线程ZMQ设备？

运行多线程ZeroMQ服务的最简单方法是为zmq.Context( nIoTHREADs )实例化相应的 nIoTHREADs > 1 。有更多的性能调整配置选项可扩展性能。查看pyzmq包装器，此ZeroMQ工具如何应用于实际的pyzmq包装器代码，并询问维护者，它们的设置和/或配置是否保持不变或就此而言尚未发布。 ZeroMQ足够灵活，可以提供实现此目的的方法。

  

...设备（这是一种单向队列）随着您增加输入连接数而无法扩展

嗯，设备既不是单向队列，也不是可伸缩的。恰恰相反。

  

是否可以多线程方式运行它？

可以。

  

扩展它的最佳方法是什么？

这在很大程度上取决于系统设计应满足的确切消息传递和信令要求。高容量，超低延迟，几乎线性缩放，自适应连接处理，应用程序域用户定义的协议只是其中一些要考虑的属性。

  

是因为队列变大了，所以才变慢了吗？

该帖子包含零条信息，既没有关于大小的信息，也没有关于速度观察和/或期望的信息。在其他有文档记录的测试设置中，如果使用零拷贝和其他基于性能的方法，那么ZeroMQ在缓冲区管理方面非常可爱，因此没有人可以提供更详细的帮助。

  

有没有办法随时知道队列有多大？

不，没有这样的“内置”功能，这将花费时间和资源进行计数。如果您的系统中需要这种附加功能，则可以随意添加这种附加功能，而不必使其他用例仅用一些此类用例的附加代码，在这些用例中，消息计数和队列大小报告是没有意义的。

  

没有REQ-REP模式的设备是否有任何负载平衡策略？

是的，有很多现成的可扩展形式化通信原型模式，还有一些可能超出现成的双边分布式行为原型基元的场景，这些场景允许构建自定义的，按要求进行控制，自己的愿望和品味的负载均衡器。