Amazon web services 哪个服务的响应时间较短？SQS vs DynamoDB

好的，我很久以前使用AWS Lambda构建了一个无服务器应用程序。我目前的申请流程如下：

API网关（1）→ Lambda函数（2）→ SQS（3）→ Lambda函数（4）→ 发电机B（5）

现在，有一些考虑：

客户端将向我的API（1）发送请求

API事件附加了一个lambda函数（2），因此它将接收API请求并对其进行处理

现在，这里是问题的切入点。在处理请求之后，必须将该处理的结果插入DynamoDB（5）。目前，我将其发送到SQS（3）并返回客户端发送的HTTP请求的响应

尽管请求已完成并得到响应，但SQS（3）消息将由另一个lambda函数（4）进行事件拉取，该函数将在DynamoDB（5）上插入已处理的消息

当我第一次原型化这个流时，我有一个假设：向SQS发送消息比在DynamoDB上插入消息要快。然而，我从来没有做过真正的基准或类似的事情，所以我的假设只是武断的

最后，问题是：哪一个动作更快？是否将已处理的请求发送到SQS或直接发送到DynamoDB

考虑到，在这两种情况下，它都将从lambda函数（2）中执行，因此，从理论上讲，由于它与AWS本身处于相同的上下文中，因此它的响应时间不会与从其他机器请求它的响应时间相同

如果这个问题的答案是：

• 直接在DynamoDB上插入更快
• 直接插入DynamoDB不会更快，但差异可以忽略不计

我可以删除SQS（3）和第二个lambda函数（4），从而得到更简单、更直接的流

---

但是，如果先发送到SQS的响应时间更长，我可能会保持此流。

如果在调用之间保持连接打开，我看到DynamoDB的响应时间低于10ms。我没有关于SQS延迟的数据

---

关于成本，您基本上是将lambda成本翻倍，并添加任何SQS成本。如果您使用按需写操作，SQS的成本比DynamoDB高33%。

您问SQS是否比DynamoDB便宜，但在您的流程中，您同时使用这两种方法……当然，只使用API网关（1）会更便宜→ Lambda函数（2）→ 发电机B（3）

就性能而言，众所周知，DynamoDB对于小的、频繁的写入速度很快，所以我不太担心这一点

---

SQS和DynamoDB响应时间之间的差异应该非常相似，除非您的DynamoDB容量配置不正确，在这种情况下，您可能会遇到节流问题。如果配置的容量不是您关心的问题，那么我建议在Lambda函数中使用计时器测试SQS和DynamoDB（或使用AWS x-ray），并确定性能差异是否值得为Deiv和Bocks响应添加SQS和额外Lambda函数的成本

让我来分享以下额外的观点，以帮助您改进建议的设计

如果您需要严格遵守异步处理，即将请求处理与响应分离，那么请坚持使用基于SQS的解决方案

如果请求处理延迟是一致的，并且API端点的使用者可以接受，那么我建议使用Diev推荐的解决方案来处理请求，持久化到DynamoDB，并将响应返回到客户端。作为奖励，您将获得较低的AWS账单（如上所述）

DynamoDB设计用于提供“一致”P99（即第99百分位）延迟，单个项目读取<10ms，单个项目写入<20ms

---

希望这有帮助

是的，我使用这两种方法是因为请求在第一个Lambda函数返回，所以如果SQS的响应时间较短，那么使用它然后在后台发送到DynamoDB会更快。编辑的答案。感谢您的回答。实际上，我不需要在后台处理请求。我只是想尽快回复你的请求。这就是我提出这个问题的原因。显然，DynamoDB的速度足够快，可以直接使用，所以我打算将我的设计更改为这种更简单、更便宜的方法。