SQS重驱动延迟配置疑问：Lambda转DLQ后延迟设置失效

这是预期行为吗？ #

没错，这是SQS当前的预期表现。当消息通过源队列的重驱动策略自动进入死信队列（DLQ）时，DLQ本身配置的**Delivery Delay（传递延迟）**并不会作用在这些消息上——它们会立刻在DLQ中变成可见状态，等着被消费。

为啥会这样？因为自动重驱动本质上是把消息从源队列“转移”到DLQ，而不是用常规的SendMessage API去发送一条新消息。只有当你主动调用SendMessage或者SendMessageBatch把消息发到DLQ时，才会触发DLQ的Delivery Delay设置。

能不能为SQS配置“重驱动延迟”？ #

SQS本身没有直接提供“重驱动延迟”这个配置项，但有几种变通方法能实现类似的效果：

方案1：在Lambda里主动控制发送延迟 #

如果你的Lambda函数能掌控失败逻辑，那可以不用依赖SQS的自动重驱动，而是在处理消息失败后，主动调用SQS的SendMessage API把消息发到DLQ，同时指定DelaySeconds参数（最大支持900秒，也就是15分钟）。

举个Python的代码例子：

import boto3

sqs_client = boto3.client('sqs')
DLQ_URL = "你的DLQ队列URL"

def lambda_handler(event, context):
    try:
        # 这里写你的业务处理代码
        handle_message(event['Records'][0])
    except Exception as e:
        # 处理失败，主动发去DLQ并设置5分钟延迟
        sqs_client.send_message(
            QueueUrl=DLQ_URL,
            MessageBody=event['Records'][0]['body'],
            DelaySeconds=300
        )
        # 注意：记得把源队列的自动重驱动策略关掉，避免消息被重复发送到DLQ

方案2：加个中间转发队列 #

你可以设置一个中间队列，把它的Delivery Delay设为5分钟，然后把源队列的重驱动目标改成这个中间队列，再给中间队列配置重驱动策略指向最终的DLQ。这样消息先进入中间队列，等5分钟后变成可见，再自动转发到DLQ（或者你也可以用Lambda消费中间队列的消息再转发）。

不过这种方式会多一层架构，需要额外维护中间队列的配置，得权衡复杂度。

方案3：在DLQ的消费端处理延迟 #

如果DLQ是被另一个Lambda或者服务消费的，那可以在消费端做判断：拿到消息后，对比它的SentTimestamp和当前时间，看看是不是已经过了5分钟。如果没到，就把消息重新放回队列，设置VisibilityTimeout为剩余的延迟时间，等时间到了再处理。

这种方法的缺点是会增加消费端的逻辑复杂度，而且会多一些API调用的开销。

总结一下 #

SQS自动重驱动到DLQ时不应用DLQ的传递延迟是正常的预期行为，你可以通过主动发送时指定延迟、加中间队列或者在消费端处理延迟这几种方式来实现类似的“重驱动延迟”效果。

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