大佬教程收集整理的这篇文章主要介绍了SQS 需要大约 10 秒来处理传入消息是否正常，是否可以使其更快？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
设置非常简单：
后端服务向 SQS 发送消息 -> SQS 触发 lambda -> lambda 代码被执行
我在后端服务向 SQS 发送消息后立即添加了日志。
然后我使用 ClouDWatch 查看了 lambda 的日志。
令我惊讶的是，后端服务日志和第一个 lambda 日志之间有大约 10 秒的间隔，这意味着 SQS 需要大约 10 秒才能再次接收、处理和发送消息。
问题
SQS 需要大约 10 秒来处理传入消息是否正常？ 如果是，能不能做得更快？
更新
多亏了评论，我才能够更多地追踪到这一点。在我的情况下，我们使用 TypeScript CDK，并且使用以下 SqsEventsource 创建 lambda：
import eventsources = require("@aws-cdk/aws-lambda-event-sources")
const eventsource = new eventsources.SqsEventsource(
sqs.Queue.fromQueueAttributes(scope,"SomEID",{
queueArn: "someArn",queuename: "someQueuename",}),{
batchSize: 100,maxBatchingWindow: cdk.Duration.seconds(5),},)
据我所知
batchSize: 100 和总的来说意味着：“如果有 100 个事件，则立即执行 lambda，或者最迟在 5 秒后执行”。
所以 10s 还是 5s 太多了（有时甚至需要 15-20s）。
这是一个错误吗？
更新 2
为了使漏洞过程更易于测试，我决定通过 Cli 直接将消息发送到队列（因此后端服务不再与此处相关）：
aws sqs --endpoint <endpoint> send-message --queue-url <queue-url> --message-body '{"test":"test1"}'
我连续执行了 10 次上述命令（执行所有这些命令最多需要 7 秒），然后检查了 ClouDWatch 中的 lambda 日志：
（我可以使用应用程序日志检查每个请求处理了多少消息，此处不可见）
如您所见，第一次和第二次 lambda 执行之间存在 16 秒的间隔（其余部分看起来不错）。由于我在最大时间内发送了所有 10 个 SQS 消息。 7 秒，那应该是不可能的。应该有最多 5 秒或最差 10 秒的差距。
这可能是什么原因？这是一个错误吗？
旁注：
我实际上遇到了这个问题，因为我的应用程序的系统测试失败了，因为它太慢了。对于系统测试，有 50% 的时间它很慢，而另外 50% 的时间它按预期工作。
我终于可以为我找出问题所在，尽管我无法确定为什么我的问题中出现了 16s 差异。
一般问题是，如果您使用一批 SQS 消息执行 lambda 函数，并且这些消息无法处理（-> lambda 抛出错误），所有 SQS 消息都会重试，延迟几秒钟。
因此，如果与无效/失败的消息在同一批次中存在有效的 SQS 消息，则可能根本不会处理它，因为首先处理失败的消息。这可能会连续发生多次，导致我的情况延迟超过 1 分钟。
不幸的是，无法告诉 AWS 一批消息中很少有消息有效而其他消息无效。如果 lambda 抛出错误，则始终重试批处理中的所有消息。
有一些 workarounds 并且我实际上选择用 try/catch 包围每个 SQS 消息的处理，并且仅在所有消息都处理完并且其中一个之前失败时才抛出错误。这仍然意味着会重试成功的消息，但至少会及时处理它们（请注意，对于这种方法，您的 lambda 需要是幂等的）。我根本不会建议这个解决方法，它只是一个带有待办事项评论的修补程序:)
以上是大佬教程为你收集整理的SQS 需要大约 10 秒来处理传入消息是否正常，是否可以使其更快？全部内容，希望文章能够帮你解决SQS 需要大约 10 秒来处理传入消息是否正常，是否可以使其更快？所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。