我正在阅读this blog post，其中作者在消息队列的上下文中提出了以下问题：
消息丢失是否重要？如果你的应用程序节点，处理请求，死了，你能恢复吗？您会惊讶于它实际上并不重要的频率，并且您可以在不保证所有消息都得到处理的情况下正常运行
起初我认为处理消息的主要目的是永远不要丢失一条消息 - 毕竟，消息丢失可能意味着酒店预订未预订、结帐未完成或任何其他功能没有实现，这对我来说似乎太像一个错误。我想我遗漏了一些东西，那么，消息传递系统可以丢失一些消息的场景示例有哪些？
【问题讨论】：
标签： message-queue messaging distributed-computing
我想可以从一些测量单位中释放一些消息，这些消息一旦提供了价值......同样对于大数据分析解决方案来说，丢失的消息不会有很大的不同
【讨论】：
这完全取决于应用程序/更大的系统。消息队列只是链条中的一个环节，可以这么说。如果末端的应用程序准备好处理丢失，丢失一些消息不是问题。如果应用程序依赖于完整的消息传递完整性，那么就会出现问题。
一个可以接受丢失的系统示例是手机的天气更新。如果一些温度/风速更新对您没有帮助，那并没有真正的危害。
现在，如果您正在运行一个核反应堆并且您失去了核心的一些温度更新，那么这就是一个问题。
我在安全关键的基础架构级系统上工作很多，并且大部分时间负责消息传递。其中许多系统明确指出消息传递可能会重新排序、复制或丢失消息；这只是涉及分布式系统和网络的生活事实。端点系统需要设计为在该环境中正常工作。因此他们跟踪消息、端到端确认、处理重复和重传等。
【讨论】：
处理消息的要点
是永远不要丢失一条消息
是的，如果人们追求某种类型的稳健性，其中故障安全措施必须采取所有应有的谨慎和预防措施，以免任何一条消息丢失，是的，您的先验表达的期望符合。
这并不意味着所有其他系统设计都必须承担所有巨大的负担并支付所有产生的成本（资源方面、延迟方面等），就像“100% 保证交付”系统所做的那样（但是，同样，只有在他们可以的情况下）。
有许多用例，其中最初发送的每条消息的绝对确定性实际上是一种反模式。
想象一个弱同步系统（包括那些根本没有反向节流甚至任何最简单形式的反馈传播的系统），其中传感器读取实际温度、声音、视频帧并发送消息该值。
每当后处理系统收到此类信息时，可能有理由不读取任何和所有“旧”值，而是读取最新值。
如果交付框架已经获得任何更新的值集，则所有“旧”值，尚未处理，只是挂在队列头的某个深度，但在队列中，可能会创建反模式，其中人们不希望必须读取和处理任何和所有这些“旧”值，而只需要读取和处理最新的值。
就像没有人会根据昨天的价格与您进行交易一样，根据读取任何和所有“旧”温度读数做出任何新的、当前的决定并没有积极的价值，这些读数仍在排队等候。
一些智能消息传递框架提供了明确的方法，用于仅从给定来源获取非常“最新”的消息 - 从而能够强制丢弃任何“旧”消息，避免由于已知的存在而无法正确读取和处理它们一个“最近”的。
这回答了关于处理消息的假定要点的原始问题。
在任何情况下，如果发生智能交付（交付原始消息内容的精确副本或完全注意），资源会尽最大努力使用，但无需花费一分钱除了“恰到好处”的智能交付之外的任何东西。
建立稳健性的成本远不止于此。
构建终极稳健性的成本甚至远不止于此。
具有如此极端要求的系统可以并且可能扩展资源节约型智能交付，以达到某些要求定义的稳健性水平，但需要一些附加成本。
相同但反过来是不可能的——如果“万能”系统要获得更纤薄的形式和时尚，以适应任何资源受限的硬件或使其“忘记”一些“旧”目前没有积极价值的消息（但相反，它构成了处理元素必须读取和处理每个“不需要的”消息，这仅仅是因为它已被传递，同时知道核心-logic 只需要最新的）。
分布式系统从许多分布式源中累积 E2E 延迟，因此任何刚性交付系统都只是阻止和惩罚唯一的一个元素，即（延迟方面）无辜 -- 接收者。
【讨论】：