所以，我有一个流程来管理一群工人，他们为每个工蜂使用 REQ/REP 和 PUB/SUB 模式。我将监视器间隔设置为 250 [ms] ，并且一切正常。
当我部署到Windows服务器上并启动资源监视器时，此节点进程的网络流量（写入的字节数）超过 64-100 [MB/s] ，并且没有＃39 ; t包括任何真正的应用程序交易，因为无论我是否启动孩子都有流量，当孩子上网时它不会减少。
怀疑我玩的间隔设置增加了值，并注意到较高的间隔值（较少经常）确实导致流量减少，但是成本是需要很长时间来检测连接/断开连接事件
现在我还没有尝试将其缩小到实际上是 REQ/REP 模式还是 PUB/SUB 模式这就是问题，但我很好奇我忽略了哪些文件可以解释这种行为。
我们可能会在下一版本中更换ZeroMQ或GRPC，但我现在有问题要回答。
我相信我已经标记了与操作环境相关的所有内容。
答案 0 :(得分：0)
当我部署到Windows服务器上并启动资源监视器时，此节点进程的网络流量（写入的字节数）超过64-100 [MB / s]
我想你已经非常了解低级ZeroMQ原生API工具如何在那里实际工作。如果没有，可以阅读在 zmq_socekt_monitor() 调用下本机API实现如何设置另一层ZeroMQ管道和管道，以便能够监控自己的活动（事件） （等）并回顾一下，Windows（本机或虚拟化平台）在 inproc:// -instance中使用 Context() -channels设置的能力如何？ （s）'IOthread池和上述蜜蜂群。尝试调整IO线程的数量，可能会以不同的方式更好地映射 ZMQ_AFFINITY ，以便拆分“ 背景 < / strong>“工作量
...
每次调用此方法都会创建一个ZMQ_PAIR套接字，并将其绑定到指定的inproc://端点。要收集套接字事件，您必须创建自己的ZMQ_PAIR套接字，并将其连接到端点。
events参数是您要监视的套接字事件的位掩码，请参阅下面的支持事件。要监控所有事件，请使用事件值ZMQ_EVENT_ALL。
每个事件都以两帧的形式发送。第一帧包含事件编号（16位）和事件值（32位），根据事件编号提供附加数据。第二个框架包含一个字符串，用于指定受影响的TCP或IPC端点。
这是我的嫌疑#1，其原因是看到~ 100[MB/s]流量@ 250 [ms] cadence，如上所述（没有MCVE，如上所述） ）。
启用所有可能的事件（在群体中）可能会产生一定量的流量，因为每个FSA事件都会报告自启动后的彩色状态，而不考虑预期的PUB/SUB + REQ/REP可扩展形式通信原型模式“状态，覆盖所有预期的ZeroMQ基础设施的连接生命周期，在{ setup | operations | termination | release}期间传播每个这样配置的监控事件 - 阶段：
{ ZMQ_EVENT_CONNECTED,
ZMQ_EVENT_CONNECT_DELAYED,
ZMQ_EVENT_CONNECT_RETRIED,
ZMQ_EVENT_LISTENING,
ZMQ_EVENT_BIND_FAILED,
ZMQ_EVENT_ACCEPTED,
ZMQ_EVENT_ACCEPT_FAILED,
ZMQ_EVENT_CLOSED,
ZMQ_EVENT_CLOSE_FAILED,
ZMQ_EVENT_DISCONNECTED,
ZMQ_EVENT_MONITOR_STOPPED
}
所以即使在第一个预期的ZeroMQ基础设施.connect()出现之前，数据也会流动。
<强>尾声：
如果在L3 +网络层上也报告了所述 [GB/s] 流量，SIGINT专家可能会更好地请求平台供应商的尽职调查和澄清，这样一个平台的自我报告（如果不是后门课程）实践，这可能解释，肯定 - 更好地停止，这样的卓越的网络exgress数据流。 有人敢说这个平台可能已被黑了吗？ 嗯，希望不是。