SQS FIFO队列搭配Lambda触发：消息处理延迟异常及优化需求

核心原因 #

你遇到的问题根源在于FIFO队列的消息组ID（Message Group ID）机制：

• FIFO队列会将同一消息组ID的消息严格按顺序处理，当某条消息被Lambda拉取处理时，同组内的其他消息会被锁定，直到当前消息被成功删除，或者可见性超时到期。
• 你提到“期间发送的新消息能立即处理”，说明这条新消息的消息组ID与前两条不同，不同消息组的消息不受彼此的锁定限制，只要有Lambda资源就会被触发。

针对性解决方案 #

方案1：拆分消息组ID（无需严格顺序场景）

如果你的业务不需要消息严格按顺序处理，给每条消息分配唯一的消息组ID（或按非顺序需求分组）：

• 这样FIFO队列会将不同消息组的消息视为独立任务，当Lambda处理完第一个消息后，第二个不同组的消息会立即被触发，无需等待可见性超时。
• 注意：你的Lambda预留并发数设为1，同一时间只能运行一个实例，但第一个实例处理完成后，第二个会立即启动，不会有等待延迟。

方案2：优化同消息组的处理逻辑（需严格顺序场景）

如果必须使用同一消息组ID（保证消息顺序），按以下步骤调整：

1. 合理设置可见性超时：将可见性超时设为Lambda最大执行时间的1.5倍（例如Lambda最大执行时间设为5分钟，可见性超时设为7-8分钟），避免因处理超时导致消息重新可见。
2. 确保Lambda处理完成后主动删除消息：Lambda处理消息成功后，要确认SQS消息被正常删除（Lambda集成SQS时，默认会在执行成功后自动删除消息，若有自定义逻辑需手动调用DeleteMessage API）。
3. 动态延长可见性超时（可选）：如果Lambda处理时间不稳定，可在处理过程中调用ChangeMessageVisibility API，根据剩余处理时间动态延长可见性超时，防止消息提前重新进入队列。

错误尝试的原因解释

你将可见性超时设为0后出现重复处理，是因为可见性超时为0意味着消息始终处于“可见”状态，Lambda会持续拉取同一条消息，导致重复执行。

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