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

Question

我正在使用Java中的Spring Cloud AWS消息传递（2.0.1.RELEASE）从SQS队列中使用。如果相关，我们将使用默认设置，即Java 10和Spring Cloud Finchley.SR2，

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

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

可悲的是，在观察该指标时，我看到了：

最大年龄不会超过5分钟（尽管我知道这已经是几天了）。如果每次收到消息时消息都变旧，假设没有收到确认并且消息未删除-而是在可见性超时过去之后又变得可用，该图的价格不会高得多吗？

我不知道这是否是春季云AWS消息传递消耗消息的特定方式，还是一般的SQS怪癖，但我的期望是如果消息在5天前被放入队列中，并且消费者未成功使用该消息，则最长期限为5天？

如果消费者收到一条消息但没有最终删除该消息，那么实际上是最长期限实际上是两次消费呼叫之间的时间长度吗？

任何人都可以确认我的期望是否不正确，也就是说，这确实是SQS预期的行为方式（它不认为使用期限是自消息首次进入队列以来的持续时间，而是认为它是是两次接听电话之间的时间？

Answer 1

基于similar question on AWS forums，这显然是带有常规SQS队列的错误，在该队列中，仅影响一条消息。

为了对此问题发出有用的警报，我建议设置一个dead-letter-queue（在配置了一定数量的消耗未删除的情况下，消息将自动传递），并警告该消息的大小。死信队列（roximateNumberOfMessagesVisible）。

Answer 2

我认为这可能与该指标对poison pill的处理有关。尝试3次以上后，该邮件将不会包含在指标中。来自the AWS docs：

收到三次（或多次）未处理的消息后， 邮件被移到队列的后面，并且 roxAgeOfOldestMessage指标指向第二倒数第二个 未收到超过三遍的邮件。这个动作 即使队列具有重新驱动策略，也会发生这种情况。