Управление потоками гуавы при предварительной загрузке и обновлении записей кэша

Question

Мы хотим использовать кеш гуавы для кэширования сторонних данных, чтобы иметь лучшее время отклика.Кэш необходимо предварительно загрузить, выполнив последовательность вызовов API (должно быть сделано ~ 4000 вызовов API).Ответ API содержит ключ кеша и его значение.Эти вызовы API должны выполняться параллельно из нескольких потоков (т. Е. Пула потоков), чтобы ускорить загрузку кэша. Каждая запись в кэше будет иметь срок действия.Это может быть установлено с помощью вызова expireAfterAccess ().После истечения срока действия записи в кэше ее необходимо автоматически обновить в фоновом режиме.Также должен быть способ (api), с помощью которого мы можем остановить это обновление фонового кэша, чтобы мы не продолжали бесконечно выполнять вызовы API.Мы вызовем этот API, как только перестанем получать пользовательские запросы через заданный интервал времени.

Можно ли делегировать управление потоками для загрузки кеша и обновления до guava?то есть, учитывая вызов API, код для сопоставления ответа json с java-объектом и дизайном значения ключа кеша, может ли guava самостоятельно выполнять предварительную загрузку и обновление?

Спасибо.

Answer 1

Автоматическое обновление в Guava можно включить с помощью CacheBuilder.refreshAfterWrite () .Соответствующая семантика описывается следующим образом:

Указывает, что активные записи могут автоматически обновляться после истечения фиксированной длительности после создания записи или самой последней замены ее значения.[...] В настоящее время автоматическое обновление выполняется при возникновении первого устаревшего запроса на запись.

При переопределении метода CacheLoader.reload() вы можете использовать пул потоков для асинхронной загрузки значений.

Проблема с этим поведением состоит в том, что у вас всегда есть несколько чтений устаревших значений, прежде чем новое значение будет загружено, если оно выполнится успешно.Альтернативная реализация кеша, такая как cache2k , запускает обновление сразу же после продолжительности.Последний подход приводит к более свежим данным, но, возможно, к большему количеству ненужных чтений.Смотрите недавнее обсуждение этого вопроса здесь: https://github.com/ben-manes/caffeine/issues/261