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
答案 0 :(得分:9)
您正在使用REST,因此基本上您可以使用Apache HTTP,NGINX或Varnish的简单HTTP反向代理来缓存HTTP请求/响应。为什么要用NoSQL来处理简单的缓存?
当然MongoDB和Redis提供了更多的功能,但你真的需要它们吗?看看另一个问题:Caching JSON objects on server side
答案 1 :(得分:2)
首次从REST端点获取数据时,将数据存储在缓存层中并返回到服务。 当您收到后续请求时,检查缓存中是否存在数据(如果该数据不存在),然后向REST请求并获取数据。
您需要在缓存层中存储数据时提及到期时间。这将阻止CRON作业,因为不是一次获取所有数据,而是仅在需要时获取它,此时检查它是否已在缓存中过期。
我更喜欢redis,因为它是最适合缓存层的一种。它是一个“NoSQL”键值数据存储,它不像MongoDB,它是一个基于磁盘的文档存储。与memcache类似,它可以在您添加新数据时逐出旧数据。如果您想要一个由多个进程,多个应用程序或多个服务器共享的高度可伸缩的数据存储,Redis是一个很好的选择。与Memcache不同,Redis提供强大的聚合类型,如排序集和列表。它具有可配置的持久性模型,其中后台以指定的间隔保存,并且可以在主从设置中运行。我们所有的Redis部署都在主从服务器上运行,从服务器设置为每分钟保存到磁盘。
作为一种进程间通信机制,它很难被击败。它的速度也使它成为一个缓存层。
答案 2 :(得分:0)
如果您碰巧使用Java,则ehcache(http://ehcache.org/)非常适合此解决方案。我们大量使用它来存储大型json对象。缓存通过xml配置。它基本上是一个键/值存储,可以独立地为每个键(缓存条目)设置超时。它是一个.jar文件。 CacheManager类处理所有细节。它只需要几行代码即可实现。