在现实世界中，有哪些例子说明消息队列系统可以接受某些消息的丢失？

Question

我正在阅读这篇博客文章，其中作者在消息队列的上下文中提出了以下问题：

如果信息丢失了，有什么关系吗？如果应用程序节点处理请求，就会死掉，您能恢复吗？您会感到惊讶的是，这实际上并不重要，而且您可以正常工作，而不需要保证所有消息都被处理

起初，我认为处理消息的主要目的是让永不丢失一条消息--毕竟，丢失一条消息可能意味着酒店预订没有预订，退房没有完成，或者任何其他功能没有完成，对我来说，这似乎太像一个bug了。我想我遗漏了一些东西，那么，有什么例子可以说明消息传递系统可以释放一些消息呢？

Answer 1

嗯，你最初的期望是：

处理消息的要点 是--从不泄露一条消息

是不对的。

是的，如果一个人为某种类型的强健而努力，在那里，防故障措施必须采取一切适当的谨慎和预防措施，这样就不会有一个信息丢失，是的，这就是你的先验表达的期望。

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

反模式案件：

有很多用例，在这种情况下，最初发送的每一条消息的绝对确定性实际上是一种反模式。

试想一下，一个弱同步的系统(包括那些根本不像后节流或任何最简单的反馈传播形式的系统)，传感器读取一个实际的温度、一个声音、一个视频帧，并发送一个带有这个值的信息。

每当后处理系统获得这样的信息时，可能就有理由不读取任何和所有的“旧”值，而是读取最近的值。

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

就像没有人会根据昨天的价格和你做交易一样，任何新的、当前的、基于阅读任何和所有“旧”温度读数的决定都是没有积极价值的，而这些数据仍在排队等待。

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

这回答了关于处理消息的假定要点的最初问题。

效率第一：

在任何情况下，如果发生了智能传递(要么提供原始消息内容的确切副本，要么说明所有内容)，这些资源都是在他们的最大努力下使用的，但是，除了“刚刚-足够”的智能传递之外，没有花一分钱在任何事情上。

构建健壮性比这更昂贵。

构建最终的健壮性，成本甚至比这还要高得多。

系统比具有这种极端需求的系统可以而且可能扩展资源高效的智能交付，从而达到某些需求定义的健壮性水平，并增加一些附加成本。

同样的但相反的情况是不可能的--如果一个“一切都可以证明”的系统要获得更精简的形式和时尚，以适应任何受限的资源硬件，或者让它“忘记”一些在此刻没有积极价值的“旧”信息(但恰恰相反，它是处理元素读取和处理每一条“不想要的”信息的必要条件，这仅仅是因为它是传递的事实，而知道一个核心--逻辑只需要最近的一条)。

分布式系统会产生来自许多分布式源的E2E-延迟，因此任何严格的传递系统都只会阻止并惩罚唯一的一个元素，即() --接收者。

Answer 2

我想可以从一些测量单位中释放几条信息，这些测量单位只提供一次价值.同样，对于大数据分析解决方案，很少丢失的消息不会产生很大影响。

Answer 3

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

一个系统的例子，将是好的损失是天气更新你的手机。如果几个温度/风向的更新不会对你产生影响，那就没有真正的危害了。

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

我在安全关键、基础设施级别的系统上做了很多工作，大部分时间我负责消息传递。其中许多系统明确表示消息传递可能会重新排序、复制或丢失消息；这只是生活中涉及分布式系统和网络的事实。端点系统需要设计成在该环境中正确工作。因此，他们跟踪消息，端到端，处理重复和重传等。