让我首先简单描述一下我们的堆栈。
- 运行 Ubuntu [m4.xlarge] 的单个 EC2 实例，具有 4 个 vCPU 和 16 GB RAM
- 运行 MySQL 8 的单个 RDS 实例，具有 2 个 vCPU 和 8 GB RAM [db.m5.large]
- 我们正在使用 cloudfront 来缓存静态资产
- 我们使用 Nginx 作为 Web 服务器
- 它由运行 Java Web 应用程序的 tomcat 实例支持
- 我们有 3 个主要应用程序，每个应用程序都在自己的 tomcat 实例中运行（Storefront 网站、管理后端、卖家平台）
店面和卖家平台通过使用 REST API 与管理后端进行对话以处理重要事件，其余则直接与 RDS for DB 集成
我们的所有应用程序均采用 Java 构建，并使用 Spring 和 Hibernate 作为框架
- 我们在所有应用程序中使用 tomcat 数据库连接池
- 我们使用内存缓存来保存完整的目录和其他不经常更改的内容，以避免数据库命中
发生了什么：
平常，根据 Google Analytics 的观察，我们的网站上有大约 125 名用户，每 2 分钟大约有 1 个订单。但有一天，当我们开展一些积极的活动时，我们网站上同时有大约 4000 名用户，每分钟大约有 18 个订单在网站上下达。因为我们承诺当天送达，所以我们的后端和卖家平台同样全力以赴地为这些订单提供服务。
我们的系统承受了 4 个小时的高负载，导致多达 20 次停机，总共停机时间约为 50 分钟。这主要是由于数据库问题造成的。
发现的问题
- 最严重的问题来自我们的后端应用程序。大约每 15 分钟后，它就会开始抛出无法获取数据库连接的错误。有时它会在一两分钟内自动解决，否则我们需要重新启动后端应用程序。
- 尽管 Storefront 并未与 Backend 连接以进行所有操作。但后端仍会抛出错误。Storefront 应用程序也变得无响应，并发生超时。
- 我们为每个应用程序分配了大约 200 个连接，但 RDS 仍然使用最多 250 个连接（包括所有应用程序）。
- 当时 RDS CPU 运行在 80% 以上
- 最严重的打击当 RDS 的 CPU 使用率达到 100% 时，就会发生这种情况，并且一直保持这种状态。一切都变得没有响应。我们需要关闭所有应用程序，重新启动 RDS 并重新启动，之后，即使负载不错，一天的剩余时间一切正常。这导致我们停机 15 分钟
问题
正如我提到的，我们的规模是中等的，因此我们没有足够的日志来了解当天发生的原因和真正发生了什么。我们可以做些什么来避免将来再次发生此类事件？我们如何做好准备，无论是改变应用程序架构、扩展硬件还是其他什么。欢迎提出所有建议
我附上了当天 RDS 的一些 CloudWatch 指标
答案1
关系数据库总是面临扩展挑战。不过，你可以尝试以下方法：
- 增加 RDS 的实例大小
- 在 RDS 中为您的数据库使用只读副本，并将应用程序的所有读取操作定向到只读副本。
- 另外，我希望您一直在关注 IOP 利用率，并且没有达到极限。如果您达到极限，则配置 IOP 会很有帮助。
- 看起来您在应用层（店面）也遇到了扩展问题。您可能希望通过将服务器置于负载均衡器后面并让其自动扩展来实现水平扩展。您可能还希望在开展活动之前使用自动扩展组增加实例，并在活动结束后缩减实例（做出计算判断）。
- 您可能还想使用断路器模式（https://martinfowler.com/bliki/CircuitBreaker.html) 位于店面和管理服务之间。