为何搭配Lambda触发器的SQS FIFO队列无法保证仅一次投递？

我在AWS官方内容中看到，将SQS FIFO队列用作Lambda触发器时，无法保证消息仅一次投递：

Amazon SQS FIFO队列确保消息组内的处理顺序遵循消息顺序，但用作Lambda触发器时不保证仅一次投递。若您的无服务器应用需要仅一次投递，建议让函数实现幂等性，可通过Amazon DynamoDB这类可扩展、低延迟的控制数据库跟踪消息的唯一属性来实现。

我知道标准队列无法保证仅一次投递是因为SQS在多服务器存储消息以实现冗余和高可用，多个Lambda轮询队列时可能导致同一条消息再次投递，但想不通SQS FIFO队列搭配Lambda触发器为什么会出现相同行为，求解释其原因和内部工作机制。

核心原因与内部机制解析 #

• Lambda的批量处理与重试逻辑
  Lambda会以批量方式从SQS FIFO队列拉取消息（同一消息组的消息会被分到同一批），然后触发函数执行。如果函数执行超时、抛出未处理的异常，或者Lambda服务本身出现短暂故障，这批消息会被自动放回队列，触发重新投递。即使FIFO队列有消息去重ID（MessageDeduplicationId），这种因执行失败导致的重投也不受去重规则限制——因为去重只针对重复发送到队列的消息，而不是因处理失败被放回的消息。

• SQS可见性超时的边界限制
  当Lambda拉取消息后，消息会进入隐藏状态（可见性超时），这段时间内其他消费者看不到该消息。如果函数执行时间超过了设置的可见性超时，或者函数进程意外终止（比如实例崩溃），消息的隐藏状态会提前结束，消息会重新出现在队列中，被Lambda再次拉取处理。FIFO队列的顺序保证不影响这个机制——它只保证消息组内的处理顺序，不阻止因可见性超时导致的重投。

• 分布式系统的固有不确定性
  SQS FIFO本身的「仅一次处理」保证，依赖于消费者在成功处理消息后主动删除消息。但Lambda是托管服务，函数的执行环境是动态调度的，如果在函数处理完消息但还没来得及向SQS发送删除请求时，执行环境被意外回收（比如资源紧张时的强制销毁），SQS会认为消息未被处理，进而重新投递该消息。这种分布式场景下的竞态条件，是FIFO+Lambda组合无法避免仅一次投递的根本原因之一。

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