SQS与Lambda批量场景下ReceiveMessage和SendMessage未批量执行问题咨询

场景 #

我通过SQS触发Lambda，针对100个队列配置如下：

• 队列配置：
  • VisibilityTimeout：330秒
  • ReceiveMessageWaitTimeSeconds：20秒
• Lambda事件源映射配置：
  • BatchSize：10000
  • MaximumBatchingWindowInSeconds：300秒
• Lambda平均调用时长为2秒

问题 #

我原本理解DeleteMessage、ReceiveMessage和SendMessage单请求最多可处理10条消息，但账单显示ReceiveMessage和SendMessage未按此批量执行。这两项操作的费用约为DeleteMessage的10倍，而消息数量比例并不符合该倍数：

疑问&解答 #

核心忽略的配置与细节 #

1. SendMessage未使用批量接口
   账单中Send的费用是Delete的10倍左右，完全对应单条发送和批量删除的请求数差异：你大概率在业务代码中使用了单条的SendMessage接口发送消息，而非批量的SendMessageBatch（单次最多可发送10条）。单条发送时每条消息对应一次请求，而Lambda处理完消息后默认会用DeleteMessageBatch批量删除，每10条消息对应一次请求，这直接导致了两者的费用比例差10倍左右。

2. ReceiveMessage的额外请求场景
   Lambda事件源映射拉取消息时，存在多个会增加请求次数的场景：

   • 凑批量的多次请求：你设置的BatchSize=10000，但SQS的ReceiveMessage单次最多拉取10条消息，因此Lambda要凑够10000条消息至少需要发起1000次ReceiveMessage请求。如果在300秒的批量窗口内没凑够指定数量，Lambda仍会触发调用，此时请求次数为实际拉取消息数除以10（向上取整）。
   • 空队列的长轮询请求：你开启了长轮询（ReceiveMessageWaitTimeSeconds=20），当队列无消息时，Lambda事件源映射仍会定期发起ReceiveMessage请求，这些请求等待20秒后返回空结果，但依然会被计入账单。若100个队列中有部分经常空闲，这类空请求会大幅拉高Receive的总请求次数。
   • 消息重试的重复拉取：虽然Lambda平均时长仅2秒，远小于330秒的可见性超时，但如果存在消息处理失败（如代码报错、调用超时），消息会重新回到队列并被再次拉取，这也会增加ReceiveMessage的请求次数。

3. 多队列的放大效应
   你有100个独立队列，每个队列的事件源映射都会独立发起ReceiveMessage请求，哪怕部分队列消息量极少，这些拉取请求也会累加，进一步推高Receive的总请求次数和费用。

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