AWS Lambda响应SQS FIFO队列触发重复执行问题咨询

我有一个由SQS FIFO队列消息触发的AWS Lambda函数，代码结构如下：

def lambda_handler(event, context):
    # 处理队列中的每条消息
    for record in event.get("Records"):
        # 处理逻辑写在这里
    return {
        "statusCode": 200,
        "body": "Function executed correctly."
    }

每当函数被SQS消息事件触发时，日志显示执行正常且无错误，但随后会莫名执行第二次，且并非由新的SQS消息触发（移除for循环也无法解决此问题）。查看日志发现，两次执行的RequestID不同，但事件Records数组中的messageId一致；第一次执行时attributes中的ApproximateReceiveCount为1，第二次为2。

因此，每次触发事件都会导致函数执行两次，我想知道这是什么原因？

我了解到幂等性对Lambda的重要性，曾考虑用messageId存入数据库来判断事件是否为重复：若当前事件的messageId与已处理的相同，则不处理。请问是否有更优方案？我是否只处理了表象而非根源？

• Lambda未在可见性超时内完成消息确认：哪怕日志显示执行正常，只要Lambda在SQS设定的可见性超时时间内没完成消息处理的确认（比如函数执行时间接近或超过超时阈值），SQS就会判定处理失败，把消息重新放回队列，触发Lambda再次执行。
• 隐性异常导致的重试：Lambda返回200不代表内部处理完全没问题，如果存在被捕获但未记录的异常，或者外部调用超时/失败，可能导致SQS未收到有效的处理确认，触发重试机制。
• 可见性超时配置不合理：如果SQS的可见性超时设置过短，Lambda还没处理完消息，SQS就会将消息标记为未处理，重新投递给Lambda。

先解决根源问题 #

1. 调整可见性超时与Lambda超时：
   • 确保SQS队列的可见性超时大于Lambda函数的超时时间（建议是Lambda超时的1.5-2倍）。比如Lambda超时设为30秒，可见性超时至少设为45秒。
   • 若处理逻辑耗时较长，同步调整两者的超时配置，避免超时导致的重复投递。
2. 排查隐性错误：
   • 仔细查看CloudWatch的完整日志，不要只看返回状态码，检查是否有被吞掉的异常、外部调用失败等细节，这些都可能导致SQS未确认处理完成。
3. 确保处理逻辑原子性：
   • 保证每条消息的处理操作（数据库写入、外部服务调用等）是原子性的，避免出现半处理状态，导致SQS触发重试。

更高效的幂等性方案 #

即使解决根源问题，SQS仍可能因网络波动等极端情况出现重复投递，以下方案比存数据库更高效：

• 用内存数据库存储已处理ID：使用Redis这类内存数据库存储已处理的messageId，设置与SQS消息保留周期一致的过期时间，查询速度远快于关系型数据库。
• 数据库层面做幂等约束：如果处理逻辑涉及数据库操作，直接将messageId（或结合业务唯一ID）设为数据库表的唯一约束，重复处理时数据库会抛出唯一键冲突，直接跳过即可。
• 利用FIFO队列特性：虽然FIFO的MessageDeduplicationId是针对发送阶段的，但处理时可以结合messageId和业务ID做双重校验，确保同一业务操作不会重复执行。

内容的提问来源于stack exchange，提问作者Arturo Avila