我在 Amazon S3 上有大量对象，其中只有一小部分是定期访问的。因此，我真的很想使用分布式缓存系统，比如 Ehcache。 （注意，我会使用 Cloudfront，但数据需要从 API 服务器访问，而不是从最终用户访问，而且我上次检查时 Cloudfront 不支持身份验证。）
谁能告诉我这是否可行、实用，或者是否存在使用 Ehcache 缓存来自 Amazon S3 的对象的库或示例？
当然，我的应用服务器是用 Java 实现的，并且运行在 Linux 环境中。
非常感谢。
【问题讨论】：
有趣的想法 - 但是，在最终深入研究之前，我想强调一下，自 2009 年 9 月起，Amazon CloudFront 就提供了身份验证，尽管可能不像您想象的那样，即您可以使用 a Signed URL to Serve Private Content：
您可以使用静态签名 URL 或 动态签名 URL。分发时使用静态签名 URL 私人内容给已知的最终用户 [...]。 在这种情况下，您创建一个签名的 URL 并使该 URL 可用于 根据需要您的最终用户。您使用动态签名 URL 分发 出于有限目的向最终用户即时提供内容 [...] 在这种情况下，您的应用程序会生成签名的 URL。
这在Overview of Private Content中有更详细的说明：
CloudFront 私有分配基于以下策略声明： 指定以下任何或所有约束：
- 指定签名 URL 有效的日期和时间的开始日期
- 签名 URL 失效的结束日期和时间
- 可以使用签名 URL 的 IP 地址或 IP 地址范围
[强调我的]
这种方法对于您的用例是否可行取决于您的解决方案的架构，只要您需要通过某种方式生成这些签名的 URL 并依次使用来自 API 服务器的那些；鉴于您的“最终用户”是 API 服务器，您可能会按照建议预先生成静态 URL，另一方面，最明显的方法可能是在 API 服务器本身中动态执行签名 URL 生成过程并缓存生成的 URLSigned URL 映射最终重用（即确实通过 Memcached 或 Ehcache）。
这种身份验证方案显然比简单的 HTTP 身份验证更麻烦，例如，另一方面它也提供了更多的灵活性，参见例如教程Restricting Access to Files in a CloudFront Distribution Based on Geographic Location (Geoblocking) 用于高级用例，AWS 博客上的Guest Post: Geo-Blocking Content With Amazon CloudFront 也对此进行了总结。
【讨论】：
我最终使用JetS3t 从 S3 读取文件并将它们存储在分布式 ehcache 集群中。到目前为止，这种方法效果很好，尽管我发现 JetS3t 创建了一个必须处理的large number of temporary files。
【讨论】：