我已经使用ZeroMQ（更具体地说是CZMQ）在Linux中为IPC实现了消息总线 . Here是我实施的 .
我的问题是， how do I know that send dropped the message when the publisher buffer is full?
在我的简单测试设置中，我使用的是具有代理的发布者 - 订阅者 . 我有一个快速发送器和一个非常慢的接收器，导致消息命中HWM并丢弃发送 . 我的例外是发送失败并出现'message dropped'错误，但事实并非如此 . 即使消息被丢弃， zmq_msg_send() 也没有给我任何错误（我可以通过查看订阅者端消息中的空白来验证这一点） .
如何知道邮件何时被删除？如果这是预期的行为并且ZeroMQ不告诉我们，那么找到我的发送是否丢弃消息的解决方法是什么？
2 回答
默认情况下，最新版本的zeromq pub / sub默认为1000条消息的SND_HWM / RCV_HWM .
这意味着如果你在一个超过1000个消息的紧密循环中爆发，它将会丢失一些 . 编写测试很简单，并为每条消息提供一个带有序列号的有效负载 .
一种选择是将_HWM都设置为0.这意味着它是无限的 .
你可以用我最近写的一些例子来解决这个问题：
https://gist.github.com/easytiger/992b3a29eb5c8545d289 https://gist.github.com/easytiger/e382502badab49856357
在一连串的消息中，它会在一个tport上发布和发布 . 如果您使用HWM，您可以在大爆发中看到，如果它不是0，它将会掉落很多
您看起来要求的是PUB / SUB不理想的容错 . 不仅可以达到HWM，而且考虑如果订阅客户端死亡并重新启动会发生什么 - 它将错过发布者在此期间发送的消息 . FWIW . 在ZMQ v2中，默认HWM对于PUB / SUB是无限的，但是在v3中已经变为1000，因为系统由于消息排队的速度比可以发送的速度快而导致内存阻塞 . 当平均消息速率在网络带宽内时，1000似乎是消息突发的合理值 . 因人而异 .
如果您只想知道消息何时被丢弃，就像在消息中添加递增消息编号并让订阅者监视消息一样简单 . 您可以选择将此号码放在自己的框架中;整体简洁将是决定者 . 我不相信有可能确定何时因为已到达HWM而特意丢弃消息 .