问Java，对缓存大量GB的策略有帮助吗？

EN

我的2美分用于大型数据存储。

首先，对于基于文件的数据存储解决方案来说，这是不够的。这基本上意味着您的数据是磁盘IO受限的，即使您是某种“基于对象的文件结构”，您也很难实现任何商业数据库(如Oracle )对其磁盘IO访问所做的优化。我过去缓存这类数据的经验是使用像Coherence缓存这样的内存缓存技术。基本上，您构建了一个服务器集群，每个服务器都有很高的内存(比如48 in )，并将所有对象缓存到内存中。可以把它想象成一个带有冗余因子的大型哈希图，你可以配置它。你可以用自定义的方式定义你的键。

其次，很明显，您的解决方案是受空间限制的，您可以考虑将一些压力转移到CPU受限制的地方-要么压缩JSON格式；要么存储二进制数据并实时转换为JSON。这应该能够将您的数据缩小到很大的比例。您需要选择适当的格式，这样CPU才不会过载，但我猜这是不太可能的。

以上是基于查询是单一的假设，即查询(日期，站)的单一组合。如果你有其他频繁的查询，那么需要使用一些支持性的数据结构，比如索引。

在Java中缓存这样大量的数据不是最好的选择。如果你的堆很大，你会遇到GC停滞，或者需要对它进行大量的调优。您可以使用BigMemory选项执行EHCache。然而，这意味着在每次请求时，CPU都需要反序列化来自堆外内存的Java对象，并再次生成JSON数据。

因此，尽管这是用Java缓存标记的，但我还是建议使用非Java解决方案。

我认为URL的响应永远不会改变，因为您正在查询过去的天气信息。所以，只要放上合适的HTTP缓存头，让前端(缓存) web服务器来做所有的事情。对于前端缓存服务器，nginx或varnish是非常常用的产品。

另一种选择是预先生成JSON文件并只提供静态文件。这并不像看起来那么糟糕。操作系统可以很好地缓存文件和内容，并且在Linux和BSD上有sendfile系统调用，因此文件内容由操作系统直接填充到TCP缓冲区中。预先生成文件版本的压缩版本也是一件好事。如果压缩在accept编码标头中，则可以将web服务器配置为自动拾取带有.gz后缀的文件。由于所有web客户端通常都支持压缩，因此这些文件将是您的操作系统保存在内存中并快速提供服务的文件。

在文件系统中只有文件的情况下，系统内存将被操作系统非常有效且完全地用于缓存。如果你把任何其他的存储或处理东西放在这个问题上，你有更多的“旋钮”要调优，我怀疑你会得到更好的结果。

祝好运!