我正在构建一个Ruby on Rails应用程序，我需要能够使用REST API来获取（Atom）feed格式的一些数据。 REST API对每秒以及每天进行的呼叫数量有限制。考虑到我的应用程序可能具有的流量，我很容易超过限制。
解决方案是在本地缓存REST API响应提要并公开提供从REST API接收的缓存提要的本地服务（Sinatra）。当然，扫地机会定期刷新缓存的饲料。
这里有2个问题。
1）其中一个REST API是一个搜索API，其中搜索结果作为ATOM提要返回。 API包含几个参数，包括搜索查询。我的缓存策略应该是什么，以便可以根据参数唯一地标识缓存的Feed？也就是说，例如，如果我搜索说
/search?q=Obama&page=3&per_page=25&api_version=4
我得到了这些参数的Feed响应。如何缓存源，以便在稍后的调用中传递完全相同的参数时，将返回缓存的源，如果参数更改，则应对REST API进行新的调用？
2）另一个问题是清扫车。我不想扫描很少使用的缓存Feed。也就是说，搜索查询Best burgers in Somalia显然不如说Barak Obama。我确实有多少消费者订阅了Feed的数据。此策略应该是在给定此搜索查询的订阅者数量的情况下，根据此数量的大小来扫描缓存的供稿。由于缓存需要在Sinatra应用程序中进行，如何实现这种扫描策略呢？一些代码会有所帮助。
我对这里的任何想法持开放态度。我希望这些机制在性能上非常出色。理想情况下，我希望在没有数据库和纯页面缓存的情况下执行此操作。但是，我愿意尝试其他事情。
答案 0 :(得分：0)
为什么要将REST服务复制为Sinatra应用程序？您可以轻松地在现有的Rails应用程序中创建一个模型来缓存Atom提要（例如，将整个提要存储为字符串）。
一个CachedFeed模型，当它的“updated_at”足够远，可以更新。 您甚至可以为cachedFeed Controller使用静态缓存来减轻系统的压力。
在Rails应用程序中使用缓存可以大大降低何时更新缓存的复杂性，甚至可以计算针对您查询的其余API执行的请求。
您可以使用模型逻辑将您拥有的电话分配给最受欢迎的Feed。搜索参数可以只是模型的属性，因此您可以轻松找到并区分它们