http://api.bitcoincharts.com/v1/markets.json（示例）
我计划访问如下所述的多个 REST 端点以获取数据，并且在某些时候，由于连接错误或服务不可用，对某些端点的访问会失败。我只对数据的最后一个快照感兴趣。为了解决这个问题，我想将最新的快照存储在数据存储（最好是 NoSQL）中，比如 Mongo 或 Redis，并希望修改应用程序逻辑以始终查看这些数据源而不是 API 端点。这将始终提供可预测的数据，我打算运行一些 CRON 脚本以定期从这些 REST 端点提取数据并将其存储在上述数据源中。
http://api.foo.com/v1/foo.json
http://api.bar.com/v1/bar.json
http://api.baz.com/v1/baz.json
【问题讨论】：
您使用的是 REST，所以基本上您可以使用简单的 HTTP 反向代理缓存 HTTP 请求/响应，例如 Apache HTTP、NGINX 或 Varnish。为什么要为简单的缓存使用 NoSQL？
当然，MongoDB 和 Redis 提供了更多功能，但您真的需要它们吗？看看另一个问题：Caching JSON objects on server side
【讨论】：
当您第一次从 REST 端点获取数据时，将数据存储在缓存层并返回给服务。 当您收到后续请求时，检查数据是否存在于缓存中，如果不存在则向 REST 请求并获取数据。
在缓存层中存储数据时需要提及过期时间。这将阻止 CRON 作业，因为不是一次获取所有数据，而是仅在需要时获取它，然后检查它是否已在缓存中过期。
我更喜欢 redis，因为它是最适合缓存层的一种。它是一个“NoSQL”键值数据存储，它不像 MongoDB，后者是一个基于磁盘的文档存储。与 memcache 类似，它可以在您添加新数据时逐出旧数据。如果您想要一个由多个进程、多个应用程序或多个服务器共享的高度可扩展的数据存储，Redis 是一个绝佳的选择。与 Memcache 不同，Redis 提供了强大的聚合类型，如排序集和列表。它有一个可配置的持久性模型，它以指定的时间间隔在后台保存，并且可以在主从设置中运行。我们所有的 Redis 部署都以主从方式运行，从服务器设置为大约每分钟保存到磁盘。
作为一种进程间通信机制，它很难被击败。它的速度也使它非常适合作为缓存层。
【讨论】：
如果您碰巧使用 Java，ehcache (http://ehcache.org/) 非常适合此解决方案。我们大量使用它来存储大型 json 对象。缓存是通过xml配置的。它基本上是一个键/值存储，可以为每个键（缓存条目）独立设置超时。它是一个 .jar 文件。 CacheManager 类处理所有细节。只需几行代码即可实现。
【讨论】：