为什么 SQS 中的 ApproximateAgeOfOldestMessage 不大于约 5 分钟

Question

我2.0.1.RELEASE在 java 中利用 spring cloud aws 消息传递 ( ) 从 SQS 队列中消费。如果相关，我们使用默认设置，java 10 和 spring cloud Finchley.SR2，

我们最近遇到了一个问题，即由于应用程序错误而无法处理消息，从而导致异常并且无法确认（删除）消息。该消息稍后会重试（这是可取的），大概是在可见性超时过后（再次使用默认值），我们还没有在此处自定义设置。

我们有几天没有发现上面的错误，这意味着消息接收计数非常高，并且消息在概念上已经在队列中一段时间​​（到现在几天）。我们考虑创建一个云监视 SQS 警报，以提醒我们将来出现类似情况。唯一合适的指标似乎是ApproximateAgeOfOldestMessage。

可悲的是，在观察这个指标时，我看到了这一点：

最大年龄不会超过 5 分钟（尽管我知道它已经有好几天了）。如果每次接收发生时消息都变旧，假设没有确认出现并且消息没有被删除 - 但是在可见性超时过后再次变得可用，如果这个图不会高很多？

我不知道这是否是 spring cloud aws 消息传递使用消息的方式所特有的，或者它是否是一般的 SQS 怪癖，但我的期望是，如果 5 天前将消息放入队列，并且消费者有没有成功消费消息，那么最大年龄将是 5 天？

事实上，如果消息被消费者收到，但最终没有被删除，那么最大年龄实际上是消费调用之间的长度吗？

任何人都可以确认我的期望是否不正确，即这确实是 SQS 预期的行为方式（它不认为年龄是自消息首次放入队列以来的持续时间，而是认为它是接听电话之间的时间？

Answer 1

我认为这可能与这个指标的处理有关poison pill。尝试 3 次以上后，该消息将不会包含在指标中。来自AWS文档：

收到一条消息 3 次（或更多）且未处理后，该消息将移至队列末尾，并且 ApproximateAgeOfOldestMessage 指标指向尚未接收超过 3 次的第二旧消息。即使队列具有重新驱动策略，也会发生此操作。

Answer 2

根据AWS 论坛上的类似问题，这显然是常规 SQS 队列的一个错误，其中仅一条消息受到影响。

为了针对此问题发出有用的警报，我建议设置一个死信队列（在可配置数量的消耗而不删除之后自动传递消息），并针对死信的大小发出警报-队列（可见消息的近似数量）。