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

Question

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

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

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

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



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

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

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

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

Answer 1

基于 similar question on AWS forums ，这显然是常规 SQS 队列的一个错误，其中只有一条消息受到影响。

为了对这个问题有一个有用的警报，我建议设置一个 dead-letter-queue (在可配置数量的消费后自动传递消息)，并警告死信队列的大小(ApproximateNumberOfMessagesVisible)。