Задонатить и смотреть →
Открой безлимитный доступ к 100+ полезных скринкастов и получай скидки на все предстоящие мероприятия

Кеширование результата

Разработка прокси-объекта для гибкого настраиваемого кеширования результатов геолокации.

  • 00:00:07 - Необходимость кэширования
  • 00:01:06 - Класс для кэширования
  • 00:01:41 - Сохранение результата
  • 00:03:32 - Применение в проекте
  • 00:04:29 - Обзор результата
  • 00:05:19 - Альтернативные комбинации
  • 00:08:28 - Префикс для ключа
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (6)
Роман

выходит если первый сервер недоступен и он в приоритете то при каждом запросе мы будем к нему стучаться и если он отвалился на долго то это не очень

Ответить
Фарух

Лучше наверное переместить ChainLocator внутрь CacheLocator и тогда если первый сервис не доступен, закешируется результат второго сервиса на определенное время, после того как кэш протухнет например через час, тогда будем снова пытаться постучаться к первому сервису, если его починили, закэшируем его результат.

Ответить
Артем

Здесь рассматривается случай, когда есть сервис, которому мы больше доверяем. В этом случае желательно получить именно его данные. Для этого помещается выше и оборачивается в CacheLocator.

Ответить
Евгений

Можно сделать простую реализацию CircuitBreaker. При ошибке кэшировать по специальному ключу, что была ошибка. Пока этот ключ не протух, запросы к локатору не делать.

Ответить
Артем

Это реализация паттерна Декоратор?

Ответить
Дмитрий Елисеев

Для кэширования это уже не просто Декоратор, а Заместитель (Прокси).

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu