消息队列系统可以接受某些消息丢失的真实场景示例有哪些?

你最初的期望是:

处理消息的要点
是为了 从不 释放一条消息

只是不正确。

好的,如果一个人努力实现某种类型的稳健性,在这种稳健性中,故障安全措施必须采取所有适当的注意和预防措施,以免丢失任何一条信息,是的,这就是你的先验表达的期望。

这并不意味着所有其他系统设计都必须像“100+%保证交付”系统那样承担所有巨大的负担并支付所有由此产生的成本(资源方面、延迟方面等等)(但同样,只有在它们能够做到的情况下)。

反模式案例:

有许多用例,其中最初发送的每一条消息的交付的绝对确定性实际上是一种反模式。

想象一下,一个弱同步系统(包括那些完全没有反向节流甚至任何最简单形式的反馈传播的系统),其中传感器读取实际温度、声音、视频帧,并发送具有该值的消息。

每当后处理系统收到此类信息时,可能有理由不读取任何和所有“旧”值,而是读取最近的值。

如果交付框架已经获得了任何更新的值集,那么所有尚未处理的“旧”值,只是挂在队列头的某个深度,但在队列中,可能会创建反模式,在这种模式中,人们不希望必须读取和处理任何和所有这些“旧”值,而只需读取和处理最近的值。

就像没有人会根据昨天的价格与你进行交易一样,基于读取仍在队列中等待的任何和所有“旧”温度读数,做出任何新的、当前的、决策都没有正价值。

一些智能消息框架提供了明确的方法,仅从给定源获取最“最新”的消息,从而能够强制丢弃任何“旧”消息,避免由于已知存在“最新”消息而正确读取和处理这些消息。

这回答了关于处理消息的假设要点的原始问题。

效率第一:

构建稳健性的成本要高于此。

系统确实有这样一个极端的需求,可以并且可能会扩展资源高效的智能交付,以达到一些需求定义的鲁棒性水平,但需要一些附加成本。

同样但反过来是不可能的——如果一个“万事俱备”的系统要获得更苗条的形式和时尚,以便适应任何有限资源的硬件,或使其“忘记”一些“旧”信息,这在此时此刻没有任何积极价值(但相反,对于处理元素来说,必须阅读和处理每一条“不想要的”消息,这仅仅是因为它被传递了,而知道核心逻辑只需要最新的一条)。

分布式系统会从许多分布式源中产生E2E延迟,因此任何刚性交付系统都只是 阻止并惩罚唯一一个元素,谁是 (延迟方面) 无辜的 --接收器。

我认为可以从一些度量单位中释放一些消息,这些度量单位可以一次性传递价值。。。。此外,对于大数据分析解决方案,很少有丢失的消息不会产生很大的影响

这完全取决于应用程序/更大的系统。可以说,消息队列只是链中的一个链接。如果末尾的应用程序准备好处理丢失,则丢失一些消息不是问题。如果应用程序依赖于整体消息传递完整性,那么就会出现问题。

例如,手机的天气更新就是一个可以接受损失的系统。如果几次温度/风的更新对你没有影响,那没有什么真正的危害。

现在,如果你在运行一个核反应堆,你失去了一些核心的温度更新,那么这就是一个问题。

我在安全关键、基础设施级别的系统上做了很多工作,并且大部分时间负责信息传递。其中许多系统明确指出,消息传递可能会重新排序、复制或丢失消息;分布式系统和网络只是生活中的一个事实。端点系统需要设计为在该环境中正常工作。因此,它们跟踪消息、端到端确认、处理重复和重新传输等。