Q54 — AWS SAA-C03 第16章

第 54/100 题 | ← 返回第16章

Q1254. 一家游戏公司有一个显示游戏分数的 Web 应用程序。该应用程序在应用程序负载均衡器 (ALB) 后面的 Amazon EC2 实例上运行。该应用程序将数据存储在 Amazon RDS for MySQL 数据库中。由于数据库读取性能下降，用户遇到了长时间的延迟和中断。该公司希望改善用户体验。哪种解决方案可以满足这一要求?

正确答案: A. 在数据库前面使用 Amazon ElastiCache（Redis OSS）缓存。

解析

对于该游戏公司 Web 应用程序而言，提升数据库读取性能并降低延迟的最佳解决方案是方案 A:在数据库前端使用 Amazon ElastiCache (Redis OSS)。具体分析如下:关键要求:提升读取性能（用户由于数据库读取速度慢而体验到延迟）。减少中断（可能由数据库瓶颈引起）。保持与现有 EC2 + ALB + RDS MySQL 架构的兼容性。选项分析:A.Amazon ElastiCache（Redis OSS）缓存最佳选择:将频繁访问的数据（例如游戏分数、用户资料）缓存在内存中，从而减少 RDS 的读取负载。显著提升读取性能（Redis 提供亚毫秒级延迟）。易于与现有应用程序集成（EC2 实例可以在回退到 RDS 之前查询 Redis）。经济高效（ElastiCache 可以水平扩展，并且比过度配置 RDS 更经济）。B.Amazon RDS 代理读取性能不是最好的:RDS Proxy 改进了连接管理（减少连接开销，防止连接风暴）。不会直接加速读取查询——它有助于扩展写入/连接，但不缓存数据。更适合写入密集型工作负载或连接池问题。C.迁移到 AWS Lambda过度且不兼容:Lambda 是无服务器的，但应用程序已经在 EC2 上运行（重写它可能会带来新的复杂性）。不能解决读取性能问题——除非与缓存配对，否则 Lambda 仍会查询 RDS。冷启动可能会加剧某些用户的延迟。D.Amazon Aurora 全球数据库对于此用例来说没有必要:Aurora Global Database 适用于多区域灾难恢复（跨区域低延迟读取）。对单区域读取性能无益（问题可能出在本地 RDS 瓶颈上，而非区域延迟）。增加了复杂性（需要 Aurora，而不是标准 MySQL）。为什么选项 A 更优:直接解决读取性能问题（缓存是处理重复查询的最快方式）。对现有架构的改动极小（只需在应用程序和 RDS 之间添加 Redis）。久经考验的游戏排行榜解决方案（Redis 广泛用于高速比分追踪）。可扩展（ElastiCache 可以随着流量的增长自动扩展）。选项A的实施步骤:部署 Amazon ElastiCache (Redis):选择 Redis（开源）以兼容类似 MySQL 的工作负载。配置“启用集群模式”设置以实现高可用性。修改应用程序:更新 EC2 实例，首先检查 Redis 中的游戏分数。如果 Redis 中没有数据（即缓存未命中），则查询 RDS 并填充缓存。使用 TTL（生存时间）来确保缓存数据的新鲜度。优化缓存性能:使用 Redis 管道进行批量查询。使用 Amazon CloudWatch 监控缓存命中率。按需扩展:如果读取负载进一步增加，则向 Redis 添加读取副本。最终答案:一个该解决方案在对现有架构的干扰最小的情况下，提供了最快的读取性能改进。