我已经看到了几个与此有关的问题，但是没有一个答案令我满意。这个问题，特别是zeromq pattern: pub/sub with guaranteed delivery相似，尽管我愿意使用任何其他zeromq机制来达到相同的效果。
我的问题是，有没有办法像ZeroMQ中的发布者-订阅者那样以扇出模式发送消息，并确保消息将被传递？似乎零拷贝的交易商可以做到这一点，但是比pub-sub混乱得多。有更好的选择吗？用这种方法除了必须编写更多代码外，还有什么缺点？
需要此理由的原因：
我正在编写代码以分析来自仪器的数据。连接到仪器的模块需要能够将数据广播到其他模块，以供他们分析。反过来，他们需要将其分析后的数据广播到输出模块。
乍看之下，使用ZeroMQ的pub-sub似乎很适合这项工作，但是如果任何订阅者速度变慢并达到高水位，消息就会被丢弃。在此系统中，由于事件连续性，仅在模块的一小部分处丢弃消息是不可接受的。所有模块都需要分析事件以使输出有意义。但是，如果没有模块收到有关事件的消息，那就很好了。因此，如果其中一个分析模块达到高水位，则可以阻止发布者（检测模块）。
我想另一种选择是在事实发生后处理丢失的消息，但这只是在处理事件上浪费时间，这些事件以后将被丢弃。
编辑：我想进一步考虑一下，我目前希望发送的消息=发送的消息，因为我正在使用inproc并在线程之间进行通信。但是，如果我要通过TCP发送消息，则即使ZeroMQ没有故意丢弃它，消息也有可能丢失。这是否意味着即使我使用阻止发送，我也可能需要处理丢弃的消息？关于使用inproc传递消息是否有任何保证？
[通常，我认为无法通过0MQ自行为pub / sub提供保证。如果您确实需要完全可靠的消息传递，则必须自己滚动。
网络本质上是不可靠的，这就是为什么TCP进行大量握手只是为了获取数据包的原因。
与以往一样，这是延迟和吞吐量之间的平衡。如果您准备牺牲吞吐量，则可以自己进行消息握手（可能使用REQ / REP）并自己处理广播。
0MQ指南对如何至少实现您想要的here部分有一些想法。
我同意SteveL。如果您确实需要100％（或接近100％）的可靠性，那么ZeroMq可能不是您的解决方案。您最好选择能够解决消息传递和持久性问题的商业消息传递产品，否则，您将在ZeroMq中编码可靠性功能，并可能会在此过程中发疯。如果您需要在应用程序和数据库之间遵循ACID标准，您是否将实施自己的应用服务器？除非您想要实现自己的事务管理器，否则您将购买WebLogic，WebSphere或JBoss来为您完成此工作。
这是否意味着即使我我可能也需要处理掉落的消息使用阻止发送？
我会避免显式阻止anything，这太脆弱了。如果在消费端出现问题，同步发送方可能会无限期挂起。您可以使用轮询和超时来解决此问题，但同样，它又是脆弱而又混乱的代码。坚持异步。
关于使用inproc传递消息是否有保证？
嗯，一件事得到保证；您无需处理物理套接字，因此可以消除任何网络问题。