SQS FIFO队列与Lambda集成：错误场景下的消息顺序问题

队列配置详情 #

{
  "sourceQueue": {
    "Type": "AWS::SQS::Queue",
    "Properties": {
      "QueueName": "dev-lambdaboilerplate-sourcequeue.fifo",
      "VisibilityTimeout": 30,
      "MessageRetentionPeriod": 1209600,
      "FifoQueue": true,
      "RedrivePolicy": {
        "deadLetterTargetArn": {
          "Fn::GetAtt": [
            "sourceQueueDLQ",
            "Arn"
          ]
        },
        "maxReceiveCount": 4
      }
    }
  },
  "sourceQueueDLQ": {
    "Type": "AWS::SQS::Queue",
    "Properties": {
      "QueueName": "dev-lambdaboilerplate-sourcequeue-DLQ.fifo",
      "MessageRetentionPeriod": 1209600,
      "FifoQueue": true
    }
  }
}

Lambda触发器配置 #

"SqspollerEventSourceMappingSQSSourceQueue": {
  "Type": "AWS::Lambda::EventSourceMapping",
  "DependsOn": [
    "IamRoleLambdaExecution"
  ],
  "Properties": {
    "BatchSize": 10,
    "EventSourceArn": {
      "Fn::GetAtt": [
        "sourceQueue",
        "Arn"
      ]
    },
    "FunctionName": {
      "Fn::GetAtt": [
        "SqspollerLambdaFunction",
        "Arn"
      ]
    },
    "Enabled": true,
    "FunctionResponseTypes": [
      "ReportBatchItemFailures"
    ],
    "ScalingConfig": {
      "MaximumConcurrency": 10
    }
  }
}

发送的两条消息详情 #

1. 第一条消息：

{
  "body": "First Message",
  "attributes": {
      "ApproximateReceiveCount": "1",
      "SentTimestamp": "1729084272552",
      "SequenceNumber": "18889389647482863616",
      "MessageGroupId": "groupid1",
      "SenderId": "testid",
      "MessageDeduplicationId": "dedupid1",
      "ApproximateFirstReceiveTimestamp": "1729084272552"
  }
}

2. 第二条消息：

{
  "body": "Second Message",
  "attributes": {
      "ApproximateReceiveCount": "1",
      "SentTimestamp": "1729084273420",
      "SequenceNumber": "18889389647705071616",
      "MessageGroupId": "groupid1",
      "SenderId": "testid",
      "MessageDeduplicationId": "dedupid2",
      "ApproximateFirstReceiveTimestamp": "1729084302591"
  }
}

实际Lambda处理流程 #

• 第一次触发：拾取第一条消息，处理失败后消息重回队列
• 第二次触发：同时拾取两条消息，第二条处理成功，第一条处理失败后重回队列
• 第三次触发：拾取第一条消息并处理成功

问题原因分析 #

SQS FIFO的消息组顺序保障是同组消息必须按发送顺序被处理完成（成功或进入死信队列）后，后续消息才能被消费者拾取，当前场景出现顺序异常的核心原因：

1. 批量读取配置（BatchSize=10）：第一条消息处理失败重回队列后，若其可见性超时（VisibilityTimeout=30秒）到期前Lambda再次轮询，SQS会将同组的第一条（已重回队列）和第二条消息打包到同一个批次返回给Lambda。
2. Lambda批量处理逻辑：若Lambda未严格按批次内消息的SequenceNumber顺序处理，或在前序消息失败时仍继续处理后续消息，就会出现第二条消息先完成的情况。
3. 可见性超时设置不合理：当前VisibilityTimeout=30秒，若Lambda函数超时接近或超过该值，会导致消息在处理完成前提前回到队列，打破顺序锁。

解决方案 #

1. 强制单条消息处理 #

将Lambda触发器的BatchSize设置为1，确保每次仅处理同消息组的一条消息，彻底避免批量处理带来的顺序问题。修改后的配置片段：

"Properties": {
  "BatchSize": 1,
  // 其他配置保持不变
}

2. 严格按顺序处理批量消息并正确报告失败 #

若需保留批量处理，必须满足：

• Lambda严格按照批次内消息的SequenceNumber从小到大依次处理
• 一旦某条消息处理失败，立即停止处理后续所有消息
• 通过ReportBatchItemFailures将未处理和失败的消息返回给SQS，让这些消息回到队列头部，保障顺序处理

3. 调整可见性超时 #

将SQS队列的VisibilityTimeout设置为Lambda函数超时时间的6倍（AWS官方推荐值），避免消息在处理过程中提前回到队列，确保同组消息的顺序锁有效。例如，若Lambda超时为10秒，VisibilityTimeout应设为60秒。

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