所以，我有一个流程来管理一群工人，它为每个工蜂使用 REQ/REP 和 PUB/SUB 模式。我将监控间隔设置为 250 [ms]，一切正常。
当我部署到 Windows 服务器并启动资源监视器时，此节点进程的网络流量（写入的字节数）超过 64-100 [MB/s] 并且不包括任何还没有真正的应用交易，因为不管我有没有启动孩子，流量都是有的，当孩子上线时，流量并没有减少。
怀疑我使用增加值的间隔设置，并注意更高的间隔值（不太频繁）确实会导致流量减少，但代价是检测连接/断开事件需要很长时间.
现在我还没有尝试将其范围缩小到实际上是 REQ/REP 模式还是 PUB/SUB 模式才是问题所在，但是我很好奇我忽略的文档的哪一部分可以解释这种行为。
我们可能会更换 ZeroMQ 以支持下一个版本或 GRPC，但我现在有问题要回答。
我相信我已经标记了与操作环境相关的所有内容。
【问题讨论】：
标签： javascript node.js windows typescript zeromq
当我部署到 Windows 服务器并启动资源监视器时，此节点进程的网络流量（写入的字节数）超过 64-100 [MB/s] p>
我猜你已经很清楚低级 ZeroMQ 原生 API 工具实际上是如何在底层工作的。如果没有，可以阅读对 zmq_socekt_monitor() 的调用下的原生 API 实现如何设置另一层 ZeroMQ 管道，以便能够监控自己的活动（events et al ) 并查看 Windows（本机或虚拟化平台）在您的 Context()-instance(s) 池中使用 inproc://-channels 设置的处理能力如何- of-IOthread(s) 和所述的蜜蜂群。尝试调整 IO 线程的数量，可能更好地以不同的方式映射 ZMQ_AFFINITY，以便拆分“ 背景 " 工作量
...
对该方法的每次调用都会创建一个ZMQ_PAIR套接字并将其绑定到指定的inproc://端点。要收集套接字事件，您必须创建自己的ZMQ_PAIR套接字，并将其连接到端点。
events 参数是您希望监视的套接字事件的位掩码，请参阅下面的支持的事件。要监控所有事件，请使用事件值ZMQ_EVENT_ALL。
每个事件作为两帧发送。第一帧包含一个事件编号（16 位）和一个根据事件编号提供附加数据的事件值（32 位）。第二帧包含一个字符串，指定受影响的TCP或IPC端点。
这是我的嫌疑人#1 看到~ 100[MB/s] 的流量@250 [ms] 节奏的根本原因，如上所述（没有MCVE，如上所述）。
打开所有可能的事件（在群体中）可能确实会产生一定量的流量，因为每个 FSA 事件自启动以来都会报告一个色彩丰富的状态，而不管预期的 PUB/SUB + REQ/REP 可扩展正式通信原型模式的状态如何，涵盖所有预期的 ZeroMQ 基础设施的连接生命周期，在{ setup | operations | termination | release}-phase 中传播每个此类配置的监控事件：
{ 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 专家最好要求平台供应商进行尽职调查和澄清，背后的原因这样一个平台的自我报告（即使不是后门类）的做法，可以解释，当然 - 更好地停止，如此显着的网络出口数据流。 有人敢说平台可能被黑客入侵了吗？好吧，希望不是。
【讨论】：