我目前在服务器端工作的设置是这样的——我有一个经理（带有轮询器），它等待传入的工作请求。一旦收到东西，它就会为工作创建工作人员（带有单独的轮询器和单独的端口/套接字），然后工作人员直接与客户端通信。
我观察到，当任何一个工作人员有一些繁忙的流量时，它会在某种程度上禁用管理器——ReceiveReady事件的触发有很大的延迟。
NetMQ 文档指出“使用轮询器接收消息比直接在套接字上调用 Receive 方法要慢。当每秒处理数千条或更多消息时，轮询器可能成为瓶颈。” 我远远低于这个限制（比如连续 100 条消息），但我想知道在单个程序中有多个轮询器是否不会进一步降低性能。
我更喜欢有单独的实例，因为代码更干净（关注点分离），但也许我违背了 ZeroMQ 的原则？问题是——在单个程序性能中使用多个轮询器是否明智？或者反过来——多个轮询器是否故意让彼此挨饿？
Poller()实例：根据事实和需求设计系统，而不是听信一些大众化的意见。
实施绩效基准并衡量有关实际实施的细节。将事实与阈值进行比较也称为基于事实的决策。
您在事件响应循环中的核心逻辑是处理几类 ZeroMQ 集成信号 / 消息输入/输出，所有这些都以非阻塞模式为主，而且您的设计必须对每个此类类花费特定数量的相对注意力。
人们可能会接受远程键盘的一些更高的进程间延迟（“跨”网络运行 CLI 接口，而您的事件循环必须满足严格要求，不要错过来自 QUOTE 流的任何“新鲜”更新. 所以必须创建一个轻量级的 Real-Time-SCHEDULER 逻辑，这将引入一个Poller()非阻塞（零等待）的高优先级，另一个对读取“慢”通道进行约 5 ms 测试的另一个一个对读取主数据流管道进行 15 毫秒测试的测试。如果您已将事件处理例程配置为在最坏情况下不超过 5 毫秒，您仍然可以处理 25 毫秒的 TAT，并且您的事件循环可以处理系统要求具有 40 Hz 的稳定控制回路周期。
不使用一组几个“专门的”轮询器将不允许一个人通过易于表达的核心逻辑获得这种级别的调度确定性，以集成到这种主要稳定的控制回路中。
我使用类似的设计来驱动基于外部 AI/ML 预测器的异构分布式系统进行外汇交易，其中交易时间保持在 ~ 70 毫秒（端到端 TAT，从 QUOTE 到达到 AI/ML由于需要匹配控制环调度要求的实时约束，因此建议提交 XTO 订单指令。
如果文档说明了轮询器的性能，在 1 kHz 以上的信号传递范围内，但没有提及信号/消息处理过程的持续时间，那么它对公众的服务很差。第一步是测量进程延迟，然后分析性能包络。所有的 ZeroMQ 工具都是为扩展而设计的，应用程序基础设施也是如此——所以忘记任何 SLOC 大小的示例吧，瓶颈不是轮询器实例，而是应用程序对可用 ZeroMQ 组件的不良使用（给定一个已知的性能范围）考虑到）——人们总是可以增加可用的整体处理能力，使用 ZeroMQ，我们从第 0 天开始就处于分布式系统领域，不是吗？
因此，在设计简洁 + 监控 + 自适应缩放的系统中，不会出现窒息现象。