Q57 — AWS SAA-C03 第17章

第 57/89 题 | ← 返回第17章

Q1357. 一家公司拥有一个电子商务应用程序，用户可以通过多个移动应用和网页应用访问该应用程序。该公司需要一个解决方案，能够通过 API 接收来自移动应用和网页应用的请求。每天的请求流量变化很大，促销活动期间流量会激增。因此，解决方案必须采用松耦合设计，确保不会丢失任何请求。哪种解决方案能够满足这些要求?

• A. 创建应用程序负载均衡器 (ALB)。创建 AWS Elastic Beanstalk 端点来处理请求。将 Elastic Beanstalk 端点添加到 ALB 的目标组。
• B. 设置一个与 Amazon SQS 队列集成的 Amazon API Gateway REST API。配置一个死信队列。创建一个 AWS Lambda 函数来轮询该队列以处理请求。 ✓
• C. 创建应用程序负载均衡器 (ALB)。创建 AWS Lambda 函数来处理请求。将 Lambda 函数添加为 ALB 的目标。
• D. 设置一个 Amazon API Gateway HTTP API，并将其集成到 Amazon SNS 主题。创建一个 AWS Lambda 函数来处理请求。将该函数订阅到 SNS 主题以处理请求。

正确答案: B. 设置一个与 Amazon SQS 队列集成的 Amazon API Gateway REST API。配置一个死信队列。创建一个 AWS Lambda 函数来轮询该队列以处理请求。

解析

正确答案是 B。设置一个 Amazon API Gateway REST API，并将其与 Amazon SQS 队列集成。配置一个死信队列。创建一个 AWS Lambda 函数来轮询该队列以处理请求。解释:该公司需要一个可扩展、松耦合且具有弹性的解决方案来处理可变的请求流量（包括销售活动期间的峰值），而不会丢失任何请求。主要要求:松耦合架构:将 API 前端与后端处理解耦。避免请求丢失:确保即使在高负载下请求也能持久保存。可扩展性:有效应对流量高峰。基于 API 的访问:通过 API 接受来自移动和 Web 应用程序的请求。为什么方案 B 是最佳选择:Amazon API Gateway REST API 为移动和 Web 应用程序提供安全、可扩展的 API 端点。Amazon SQS 集成将 API 前端与后端处理解耦。将请求存储在队列（持久存储）中，确保即使在高负载下也不会丢失任何请求。通过缓冲请求直至可以处理，来应对流量高峰。死信队列 (DLQ) 捕获失败的请求，以便重新处理或进行调试。AWS Lambda 轮询队列能够自动扩展规模，处理到达的消息。无需手动扩展（与基于 EC2 的解决方案不同）。其他选项错误的原因:A. ALB + 弹性豆茎紧密耦合（ALB 直接路由到 Elastic Beanstalk，在流量高峰期可能难以应对）。没有内置队列机制。如果 Elastic Beanstalk 过载，请求可能会丢失。可扩展性不如基于队列的解决方案。C. ALB + Lambda（作为 ALB 靶标）Lambda 作为 ALB 目标并不适用于流量变化的情况。ALB 需要 HTTP 响应，但 Lambda 在高峰期可能无法快速扩展。由于没有内置队列机制，如果达到 Lambda 并发限制，请求可能会被丢弃。处理流量高峰的能力不如SQS。D. API 网关 HTTP API + SNS + LambdaSNS 是一个发布/订阅系统，而不是队列。无法保证只处理一次（消息可能会重复或丢失）。没有内置重试机制（与 SQS 不同）。在确保不丢失请求方面，可靠性不如 SQS。对比表:选项架构解耦无丢失请求?可扩展性最佳适用于AALB Elastic Beanstalk紧耦合（无队列）中等传统Web应用程序BAPI网关SQS Lambda松耦合（SQS持久化）高可变流量，无丢失请求CALB Lambda半解耦（无队列）中等简单API后端DAPI网关SNS Lambda松耦合（SNS可能丢失/重复消息）高事件驱动的发布/订阅结论:方案 B 是最佳解决方案，因为:SQS 确保不会丢失任何请求（即使在流量高峰期）。Lambda 会自动扩展以处理排队的请求。死信队列通过捕获失败的消息来提高可靠性。松耦合架构提高了弹性和可扩展性。避免选择 A、C 和 D（它们缺乏适当的排队机制或耦合性太强）。