Zmq用于随机接收和回复

Zmq for random recv and reply

本文关键字：回复 用于 随机 Zmq      更新时间：2023-10-16

我有两个关于Zmq的问题：-

1） 我正在实现一个服务器，它将每分钟接收10K个请求，然后将这些请求重定向到后端。从后端获得响应后，它将发送回响应。我不能使用请求/回复，因为这种模式的限制是recv/reply应该是同步的。有人能建议我在这种情况下使用什么吗。

2） 我是否也需要在其中实现多线程。

提前谢谢。

让我首先回答Q1-对性能的要求Q2-如果需要多线程：

ZeroMQ传输开销时间是多少

从琐碎的性能测试、有意添加TCP传输包装开销，您可能会在每个发送的消息的[usec]中体验ZeroMQ消息处理层的"成本"。

                         21.936  [usec]/MSG
                        111.280  [usec]/MSG
                         39.714  [usec]/MSG
                         37.080  [usec]/MSG
                         11.351  [usec]/MSG

要了解消息批量大小的影响缓解，请阅读使用增量大小重新测试

>>> [ sender( nBatchSIZE = x ) for x in ( 1, 10, 100, 1000, 10000, 100000, 1000000 ) ]
sent       1 ... RUN took:       58  [usec] i.e.  58.0  [usec]/MSG
sent      10 ... RUN took:      156  [usec] i.e.  15.6  [usec]/MSG
sent     100 ... RUN took:     1071  [usec] i.e.  10.7  [usec]/MSG
sent    1000 ... RUN took:    10561  [usec] i.e.  10.5  [usec]/MSG
sent   10000 ... RUN took:   106478  [usec] i.e.  10.6  [usec]/MSG
sent  100000 ... RUN took:  1333242  [usec] i.e.  13.3  [usec]/MSG

根据这些数字，您的Q1系统在大小合理的MSG（不包括多GB BLOB）上的10k/min事件流不会有问题

因此，处理性能受到后端阶段的限制

关于Q2使用内容的建议:

CCD_ 1因此从表中移出。因此，与其考虑多线程，不如考虑任何可扩展性能的方法来提高端到端处理能力——为REQ/ROUTER||ROUTER/REQ等负载均衡器使用更高级的方案，您既可以提高处理速度，也可以添加一些故障解决功能。检查Single&多集群体系结构

对于您的消息量，这一切都与消息大小有关。假设一个大致"典型"的消息大小（比如说，通常高达几百字节）和一个可以处理该吞吐量的系统（例如，如果你要预加载消息而不是用ZMQ接收消息，它是否足够有效地处理你的消息量？），那么你就不会为每分钟10k条消息而汗流浃背。你可能每秒钟都这样做（正如你在另一个答案中看到的那样）。

ZMQ将支持您正在寻找的任何消息模式，但您必须提供更多信息来确定哪种模式最适合您。指南中有很多好的例子。

相关文章：