我的 sqs 队列每天收到 100 万条消息（例如，发送的消息数），而每天收到的空消息数约为 250 万条，因此我想象 1 个月总计大约有 1.05 亿条消息，但亚马逊账单显示其每月请求数为 2.55 亿条。
Q: 请求的 sqs 值是如何计算的？
每个命令算作 2 个请求吗？
答案1
每次 API 交互都会按请求量计费ceil(payload_size_kb / 64kb)，因此每个请求（发送、接收、空接收）都会按 1 到 4 个请求量计费（最大有效负载为 256kb）。
看https://aws.amazon.com/sqs/pricing/#request_pricing。
如果每天有 2.5M 个空接收，那么要么是消费者数量非常多，要么就是您没有使用长轮询。您绝对应该使用长轮询。我从未遇到过不合适的情况。
长轮询有助于减少使用 Amazon SQS 的成本，因为它可以减少空响应的数量（当 ReceiveMessage 请求中没有可用的消息时）以及错误的空响应（当有可用消息但未包含在响应中时）。
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html
长轮询有时会被误解，因为队列参数被称为接收消息等待时间和等待时间秒数有时会误解为消费者将等待或延迟这么多秒……但事实并非如此。这只是消费者在 0 条消息可用时等待的时间。当有消息可用时，它仍会立即返回。如果队列为空，并且消费者在下一条消息到达时，例如在 20 秒的长轮询中等待了 7 秒，则消费者不会等待剩余的 13 秒。新消息会立即返回。
您几乎总是希望使用长轮询，并使用最大可能值 20 秒。这个值实际上应该是默认值，消费者想要其他值时应该被要求指定它。
如果您的消费者可以一次处理多条消息，将请求的消息数量增加到最大值 10 也会减少可计费请求的数量。同样，将此值设置为大于 1 不会增加等待时间。如果可用消息数少于最大可用消息数，则在长轮询时会立即返回可用消息数。只有当可用消息数为 0 时，您才需要等待。