Я создаю приложение Ruby on Rails, где мне нужно иметь возможность использовать API REST для извлечения некоторых данных в формате фида (Atom). API REST имеет ограничение на количество вызовов, совершаемых как за секунду, так и за день. И учитывая объем трафика, который может иметь мое приложение, я бы легко превысил лимит.
Решением этой проблемы будет локальное кэширование фида ответов API REST и предоставление локальной службы (Sinatra), которая обеспечивает кэшированный фид в том виде, как он получен от REST API. И, конечно, уборщик периодически обновляет кэшированный канал.
Здесь 2 проблемы.
1) Одним из API REST является API поиска, в котором результаты поиска возвращаются в виде ленты ATOM. API принимает несколько параметров, включая поисковый запрос. Какой должна быть моя стратегия кэширования, чтобы кэшированный фид мог быть однозначно идентифицирован по параметрам? То есть, например, если я ищу, скажем
/search?q=Obama&page=3&per_page=25&api_version=4
и я получаю ответ от фида по этим параметрам. Как мне кэшировать канал, чтобы для точно таких же параметров, переданных в вызове через некоторое время, возвращался кэшированный канал и, если параметры изменились, необходимо было сделать новый вызов в REST API?
2) Другая проблема касается уборочной машины. Я не хочу подметать кэшированный канал, который редко используется. То есть поисковый запрос Best burgers in Somalia
, очевидно, был бы гораздо менее желательным, чем, скажем, Barak Obama
. У меня есть данные о том, сколько потребителей подписались на канал. Стратегия здесь должна заключаться в том, чтобы, учитывая количество подписчиков на этот поисковый запрос, сканировать кэшированные каналы в зависимости от того, насколько велико это число. Поскольку кэширование должно происходить в приложении Sinatra, как можно было бы реализовать такую широкую стратегию? Некоторый код поможет.
Я открыт для любых идей здесь. Я хочу, чтобы эти механизмы были очень хорошими с точки зрения производительности. В идеале я хотел бы сделать это без базы данных и чистого кэширования страниц. Тем не менее, я открыт для возможности попробовать другие вещи.