SQS如何跟踪消息?

Question

我有一个非常标准的将SQS提供给Lambda的设置。lambda读取消息并向定义的端点发出web请求。

如果在处理SQS消息期间遇到由于消息形式导致的异常，则将该消息放入死信队列。

如果我在web请求中遇到错误，我将消息放回馈送队列，以便在稍后的时间发出HTTP请求。

这似乎工作得很好，但我们刚刚遇到了一个问题，HTTP端点关闭了4天，馈送队列丢弃了消息。我想这与队列的保留期设置有关。

1. 是否有一种方法可以知道，在lambda中，消息被重播了多少次?

2. 馈线队列如何知道重新进入队列的消息与最初放入队列的消息相同?

3. 我目前没有显式地从队列中删除消息。没有这个，似乎没有引起任何问题，没有重新处理消息或任何事情。我应该明确地删除它们吗?

Answer 1

正常的流程是:

• 触发AWS Lambda函数，并通过event参数传递消息
• 如果Lambda函数成功处理消息，它应该返回一个"成功"代码(200)，消息将自动从队列
中删除。
• 如果Lambda函数无法处理消息，它应该返回一个"失败"代码(例如400)，Amazon SQS将自动尝试重新处理消息(除非它已超过重试计数)
• Lambda函数失败(例如由于超时)，Amazon SQS将自动尝试重新处理消息(除非它已超过重试计数)
• 如果消息超过了重试次数， Amazon SQS将消息移动到死信队列

回答您的问题:

1. 如果您希望自己负责这些活动，您可以在消息上使用ApproximateReceiveCount属性。在请求中，看起来你应该添加AttributeNames=['ApproximateReceiveCount']，但是文档有点矛盾。您可能需要使用All代替。
2. 由于您正在向队列发送新消息，Amazon SQS是而不是意识到这是同一个信息。该消息不是're-enqueued'，因为它是一条新消息。
3. 当你的Lambda函数返回'success'(200)时，消息将被从队列中删除。

你可以考虑使用重试和死信队列的标准功能，而不是自己实现那个逻辑。