DynamoDB (DDB) 是自然的选择，因为它与 Cassandra 最相似，并且满足我们的复制（通过全局表）和延迟要求。然而，DDB 每行有 KB 的限制，这不足以像我们使用 Cassandra 那样存储我们的客户站点页面。因此，我们选择将实际网站 HTML 作为对象存储在 S 中，并启用双向、跨区域复制。 DDB 和 S 配对提供了我们所需的可扩展性和全局数据复制，但我们在研究（和后续测试）中注意到，S 对象复制（即使是小对象）比 DDB 全局表复制慢得多。
额外的几秒钟是可以忍受的，但我们发现即使是 KB 的 S 对象也可能需要一分钟或更长时间才能复制到其他区域。我们的客户发布网站并立即在浏览器中测试它是很常见的，因此我们知道这种延迟对于我们的用例来说是不可接受的。为了解决这个问题，我们最终将每个站点资产的巴西移动数据预期 S 版本存储在 DDB 记录中，并将其与从 S 获取的对象进行比较。如果我们检测到版本不匹配，我们会直接从上次写入资产的远程区域中的 S 实例中读取，以避免提供过时的内容。
缓存 Redis 缓存帮助我们在本地系统中实现了出色的延迟（约 毫秒）。，即使缓存未命中也很快（约 毫秒）。然而，随着 S 的引入，我们现在的数据存储比我们之前的解决方案慢了一个数量级，使得缓存未命中的成本显着增加。 为了避免使用 S 固有的延迟损失，我们利用 ElastiCache Redis 作为我们平台的缓存层。 ElastiCache 使我们能够灵活地在区域级别调整集群规模，以在性能和成本之间找到适当的平衡。为了保持尽可能高的缓存命中率，每当 S 中更新站点资产时，我们都会触发 Lambda，主动更新任何现有的 Redis 记录
發表於 2024-4-18 12:35:26
