我希望自己在使用 SQS 时没有犯过的 10 个常见错误

Amazon SQS 是一款功能强大的服务，适用于传统或无服务器应用程序中的消息传递，但它也面临着一系列挑战。我整理了一份常见错误和最佳实践列表，以帮助您更有效地使用 SQS。我还发布了Swarmion SQS 合约，帮助您避免这些陷阱，专注于您的业务逻辑。

TL;DR;

配置

• ❌ 不要期望 SQS 消息按照发送的顺序被使用
• ❌ 不要设置太短的保留期
• ❌ 不要设置太小的可见性超时
• ❌不要使用 Lambda 保留并发来控制吞吐量

制片人

• ❌不要发送消费者无法处理的消息
• ❌ 不要单独发送消息
• ❌ 不要发送太多消息SendMessageBatchCommand或批量发送太大消息
• ❌不要忘记处理SendMessageBatchCommand结果
• ❌ 不要向 SQS FIFO 队列发送太多消息
• ❌ 不要忘记使用MessageGroupeIdSQS FIFO 队列
• ❌ 不要uuid()使用MessageDeduplicationId

消费者

• ❌ 处理一批 SQS 消息时不要抛出错误

🤔 是的，有 12 个。但前 10 名的标题听起来更好

SQS 配置

🙅 错误：期望消息按照发送的顺序被消费

💥 影响：🐛 稳定性。消息的处理顺序不可预测。

✅ 解决方案：如果您需要按精确顺序处理消息，请使用 SQS FIFO

🙅 错误：保留期设置得太短

💥 影响：🐛 稳定性。消息可能会在处理之前就被删除，尤其是在延迟或多次重试的情况下。这可能是一场调试的噩梦。

✅ 解决方案：如果您计划使用延迟或重试，请设置一个宽松的保留期。保留期不收费。

🙅 错误：可见性超时设置过小

💥 影响：🐛 稳定性。如果消息的可见性超时在第一个处理器删除它们之前到期，则消息可以被处理多次。

✅ 解决方案：AWS 建议将可见性超时设置为预期消息处理持续时间的三倍。

🙅 错误：使用 Lambda 保留并发来控制吞吐量

💥 影响：🐛 稳定性。由于 Lambda 服务返回的节流错误，消息可能会丢失，这可能导致它们未经处理就被发送到 DLQ。

✅ 解决方案：使用MaxConcurency事件源映射的参数，而不是 Lambda 保留并发。

制片人

🙅 错误：发送消费者无法处理的消息

💥 影响：🐛 稳定性。消费者会抛出错误，导致消息丢失或行为异常。

✅ 解决方案：在生产者和消费者之间强制建立强大的接口。

💡您可以使用Swarmion 合约来创建和强制执行 lambda 与使用它们的服务之间的接口。

🙅 错误：单独发送消息

💥 影响：⚡💰 性能和成本。每条消息都以 HTTP 请求的形式发送，这会增加时间和成本。

✅ 解决方案：用于SendMessageBatchCommand批量处理最多 10 条消息。一个批量请求按一个请求计费。

💡您可以使用sendMessagesSwarmion SQS 合约的实用程序发送多条消息，而无需担心技术方面的问题

🙅 错误：发送过多消息SendMessageBatchCommand或批量发送过大消息

💥 影响：🐛 稳定性。SendMessageBatchCommand最多可以批量处理 10 条消息，总大小不超过 256KB。超过这些限制将导致批量处理被拒绝，并可能丢失消息。

✅ 解决方案：批量发送最多 10 条消息，确保总大小在限制范围内。

💡 sendMessagesSwarmion SQS 合约实用程序提供了遵循这些规则的自动批处理功能。只需传递一个消息数组，它就会处理剩下的事情。

🙅 错误：忘记处理SendMessageBatchCommand结果

💥 影响：🐛 稳定性。SendMessageBatchCommand如果消息被限制，则不会抛出，它们会在响应中返回。

✅ 解决方案：处理返回的失败批次项目SendMessageBatchCommand并重试。

💡Swarmion sendMessagesSQS 合约实用程序会自动重试受限制的消息并默认抛出错误以避免出现静默错误。

🙅 错误：向 SQS FIFO 队列发送过多消息

💥 影响：🐛 稳定性。FIFO队列每秒的请求数被限制为 300 个，如果未处理，则会导致一些消息丢失。

✅ 解决方案：使用高吞吐量 FIFO 队列或/和控制发送方的吞吐率。

💡Swarmion sendMessagesSQS 合约的实用程序提供了一个throughputCallsPerSecond参数来精确控制吞吐量。

🙅 错误：忘记使用MessageGroupeIdSQS FIFO 队列

💥 影响：⚡性能。所有消息将一次处理一条。

✅ 解决方案：使用MessageGroupeId启用消息组的并行处理。按相关用途对消息进行分组，以便并行处理不相关的消息。

🙅 错误：使用uuid()asMessageDeduplicationId

💥 影响：🐛 稳定性。消息可以被多次处理。

✅ 解决方案：MessageDeduplicationId必须是你的消息内容的哈希值

消费者

🙅 错误：处理一批 SQS 消息时抛出错误

💥 影响：⚡🐛 性能和稳定性。达到可见性超时后，将重试整个批次。某些消息将被多次处理或部分处理。由于没有消息被删除，这会导致队列堵塞。

✅ 解决方案：单独捕获错误并删除已成功处理的消息。使用 lambda 事件源映射，使用ReportBatchItemFailures函数响应类型并返回未处理的消息messageIds。

💡您可以使用getHandlerSwarmion SQS 合约的实用程序在您的处理程序周围生成一个包装器，以单独处理消息、捕获错误并向 SQS 报告失败的消息。

结论

希望这些见解能帮助您避免我在使用 SQS 时遇到的常见错误。请分享您的经验以及其他有效使用 SQS 的技巧。