我如何决定在这个特定的SQS上设置什么TTL

Question

我有一个问题陈述，我需要决定在 SQS 消息上设置什么 TTL。

我有一个 SQS，我可以在其中收到复制交易详细信息的消息。如果 txn 被拒绝，则处理消息是没有用的。例如，假设 copyDetail SQS 消息在 T+0 时添加到队列中。由于断电等问题，目前服务只能在 T+n 时刻处理消息。如果“n”没有上限，如果我有数百万条陈旧的 copyDetail 消息，我将无法处理新的 copyDeail 消息，因为我的处理将忙于复制陈旧的详细信息，而我的新请求也被阻止。因此，我们需要评估如何为此类消息设置 TTL。

局限性。

• 我无法联系其他服务来决定交易是否有效。在进行 copyDetail 处理时，我们无法知道 txn 的状态。

注意

特定交易的有效期为 20 分钟。只是。

我正在考虑应用 30 分钟的保留期。但即使在此之后，如果服务获取 copyDetail 的消息，即使事务在早期阶段失败，它也会处理该消息。

有没有可行的解决办法。或者我应该拒绝设置消息 TTL 的想法

Answer 1

我觉得如果消息超过 20 分钟，它们就没用了？如果是这种情况，最简单的解决方案是将队列的 TTL 设置为 20 分钟（或稍短一些 - 您可能需要在消费者发生故障后留出一些处理时间来清除积压的消息）。这种方法意味着无论消费者是否运行，只有可处理的项目才会保留在队列中（但您将“释放”所有不可处理的消息）。如果消费者失败，那么稍后重新启动，它不会浪费精力处理超过 20 分钟的明显无法处理的消息。

我说的是幼稚的解决方案，因为在现实世界中，您往往想了解故障并可能采取行动（例如，记录故障、提醒某人、启动额外的消费者来处理大量消息等）。您可能还需要更细致的系统特定行为，例如在使用者暂时失败的情况下延迟重新处理失败的消息。我建议阅读 AWS SQS 文档，特别是可用的队列/消息属性（用于延迟和重新处理策略），以及如何使用死信队列作为处理未处理消息的更好方法。