首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >如何避免丢弃消息

如何避免丢弃消息
EN

Stack Overflow用户
提问于 2013-08-02 03:50:14
回答 3查看 7.8K关注 0票数 4

我见过几个关于这方面的问题,但没有一个问题得到令人满意的答案。这个问题,特别是zeromq模式: pub/sub,保证交付是相似的,尽管我愿意使用任何其他的零q机制来达到同样的效果。

我的问题是,是否有任何方法可以像ZeroMQ中的publisher-订户那样,在保证消息将被传递的情况下,以一种过时的模式发送消息?似乎一个零拷贝的经销商可以做到这一点,但它会比酒吧-潜艇混乱得多。还有更好的选择吗?除了编写更多的代码之外,这样做还有什么缺点呢?

需要这样做的理由:

我正在编写一个代码来分析来自于仪表的数据。连接到仪器仪表的模块需要能够将数据广播到其他模块进行分析。反过来,他们需要将分析过的数据广播到输出模块。

乍一看,与ZeroMQ的酒吧-潜艇似乎是完美的工作,但如果任何订阅者慢下来,并击中高水印信息会被丢弃。在此系统中,由于事件的连续性,仅在模块的一小部分上删除消息是不可接受的。为了使输出有意义,所有模块都需要分析一个事件。但是,如果没有模块接收到事件的消息,就可以了。由于这个原因,如果其中一个分析模块击中了高水印,就可以阻止publisher (检测模块)。

我认为另一种选择是在事实发生后处理丢失的消息,但这只是在以后将被丢弃的事件上浪费处理时间。

编辑:我想,考虑到这一点,目前我希望发送一条消息=消息,因为我使用inproc并在线程之间进行通信。但是,如果我要通过TCP发送消息,即使ZeroMQ没有故意丢弃消息,也有可能丢失该消息。这是否意味着即使我使用阻塞发送,也可能需要处理丢弃的消息?有关于inproc的消息传递的任何保证吗?

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2013-08-02 11:22:38

一般来说,我认为没有办法用0MQ为pub/Sub本身提供保证。如果您真的需要完全可靠的消息传递,那么您将不得不使用自己的消息。

网络本质上是不可靠的,这就是为什么TCP做这么多握手只是为了传递数据包。

和以往一样,它是延迟和吞吐量之间的平衡。如果您准备牺牲吞吐量,您可以自己进行消息握手--也许使用REQ/REP --并自己处理广播。

0MQ指南提供了一些关于如何实现至少一部分您想要的这里的想法。

票数 6
EN

Stack Overflow用户

发布于 2013-08-02 23:47:55

我同意SteveL的观点。如果您确实需要100%的可靠性(或接近它),ZeroMq可能不是您的解决方案。您最好使用保证消息传递和持久性的商业消息传递产品,否则,您将在ZeroMq中编写可靠性特性,并可能在此过程中拔出头绪。如果您需要在应用程序和数据库之间执行ACID,您会实现自己的应用服务器吗?除非您想要实现您自己的事务管理器,否则您可以购买WebLogic、WebSphere或JBoss来帮助您。

这是否意味着即使我使用阻塞发送,也可能需要处理丢弃的消息?

我不会明显阻止任何东西,它太脆了。如果消费端出现问题,同步发送方可能会无限期挂起。您可以使用轮询和超时来解决这个问题,但同样,它是脆弱和混乱的代码;坚持异步。

有关于inproc的消息传递的任何保证吗?

好吧,有一件事是有保证的;你没有处理物理套接字,所以任何网络问题都会被消除。

票数 5
EN

Stack Overflow用户

发布于 2021-09-06 02:07:06

这个问题出现在搜索引擎上,所以我只想更新一下。

您可以阻止ZeroMQ在使用PUB套接字时删除消息。您可以设置NODROP选项,这将在发送缓冲区已满时引发错误。

有了这些信息,您就可以像前面提到的这里那样,创建一个类似于死信队列的东西,并继续尝试在两者之间进行重发。

当前可能无法有效地处理此问题,因为在ZeroMQ中的发送缓冲区不再满时,似乎没有一种方法可以得到通知,这意味着计时睡眠/轮询可能是确定发送队列是否再次有空间以便可以发布消息的唯一方法。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/18008482

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档