我有一个电子商务网站，每天有大约 30,000 名用户，会话超过 50,000 次。我们正在使用 RDS m5.xlarge 实例。我们在日常的读取或写入操作中没有遇到任何问题。但偶尔我们会面临以下挑战：
- 有时候，由于促销或积极营销，我们的用户数量会增加一倍以上，这时我们的 CPU 会在一天内多次达到 100%
- 偶尔，当进行一些繁重的写入时，读取会变得很慢
考虑到这一点，我无法判断是否应该进一步垂直扩展 RDS 实例或启动只读副本。在做出这个决定时，我想考虑两点：
- 拥有读取副本是否可以帮助我在高流量的日子里消除进一步垂直间隔数据库的需要？
- 我能否通过读取副本降低或保持成本不变，同时实现更高的可扩展性？
我在 m5.xlarge 实例上的平均使用情况如下：
- CPU 使用率 40%
- 数据库连接数 100
- 已使用 RAM 6 GB
- 125 写入 IOPS
- 3 读取 IOPS
除了 CPU 之外，使用率似乎很低，读取副本是一种在不增加成本的情况下实现更高可扩展性的方法吗？
答案1
听起来您需要的是一个自动扩展的 RDS，但不幸的是它并不存在于计算中。
增加 RDS 大小
如果您增加实例大小，则 24/7 的费用会更高。这是最简单的解决方案，应该可以减少您的许多问题。如果费用不是问题，这可能是最好的解决方案。
只读副本
另一个主要选项是只读副本。您必须修改软件才能使用只读副本，因为它将具有与主数据库 URL 不同的端点。例如，您可以将所有写入发送到主数据库，并将所有读取发送到只读副本。只读副本的更新可能略微落后于主数据库。您甚至可以减小主数据库的大小 - 但您需要进行基准测试或对您的方法采取保守态度。
您可以考虑在任何预期的重大事件发生之前手动启动只读副本。这将是手动的，需要一些时间，并且您的应用程序必须应对有时（但并非总是）存在的数据库。
缓存
根据您的访问模式，在 Redis / Memcached 中缓存数据可能会大大减少数据库负载，使您无需更新数据库。当然，这依赖于必须多次读取相同的数据，并且有足够的缓存存储空间。
极光
你可以考虑适用于 MySQL 的 Amazon Aurora我自己没有用过它，但它的扩展性非常好 - 尽管每个单独的交易可能不如标准 RDS 那么快。
数据库优化
另一个选择是查看哪些内容占用了数据库容量并优化“昂贵”的查询或索引。如果您有简单的查询并且负载很高，那么这可能没有帮助。