一个生产环境的 Aurora MySQL 集群是一个单写入节点，并且有大量的报表查询。该集群由于高 CPU 和达到最大连接数而出现间歇性性能问题。一名 SysOps 管理员需要稳定性能。哪种解决方案可以满足此要求？

创建 Aurora Replica 是解决此问题的最佳方案。Aurora Replica 提供只读副本，可以分担主实例的读取负载，从而降低主实例的 CPU 利用率和连接数。通过配置 Auto Scaling 策略，可以根据 CPU 利用率自动添加或移除副本，确保在高峰期有足够的读取能力，并在低峰期节省成本。将报表查询指向只读端点，可以确保这些查询不会影响主实例的写入性能。 其他选项的不足： 在另一个可用区中预置第二个单节点 Aurora MySQL 集群并让报表使用该备用集群：这会增加管理复杂性，并且报表查询仍然会直接访问数据库，无法有效扩展读取能力。 实现一个 Lambda 函数来缓存报表查询的结果：Lambda 缓存适用于特定场景，但对于大量、复杂的报表查询，可能无法完全覆盖所有数据，且缓存失效机制需要额外管理。 部署一个多节点 ElastiCache 集群：ElastiCache 适用于缓存频繁访问的数据，但对于需要实时查询最新数据的报表，可能无法满足要求，并且需要额外的应用程序逻辑来管理缓存命中和未命中。