Spring Boot Redis: распределенное кэширование объектов из Backend Services для параллельных запросов потребителей для одного и того же объекта - PullRequest
1 голос
/ 05 февраля 2020

Я не знал, как лучше объяснить мою задачу в заголовке.

Текущая настройка заключается в том, что я использую Spring Rest Service в качестве "промежуточного слоя" для преобразования данных бэкенда. , что является огромным ответом, более «дружественным» способом.

Это, например, структура бэкэнда:

public class Customer
{
   private String id;
   private String bankAccount;
   private String customerName;
}

Промежуточное программное обеспечение в настоящее время кэширует ответ от Бэкэнд в Redis. Он также имеет следующие конечные точки:

public class ServiceController
{
   getBankAccountById(String id);
   getCustomerNameById(String id);
   getCustomerObjectById(String id);
}

Все запросы производят внутренний вызов для объекта клиента и кэшируют его в redis, если ни один объект уже не присутствует.

Но в многопоточная среда, особенно в «облачной» / многоэкземплярной среде, если потребитель выполняет n-запросов (# 1 getBankAccountById () # 2 getCustomerNameById () и т. д. c. параллельно - точно такая же миллисекунда) , что только один единственный запрос запускается для «реального» бэкэнда?

Моя цель - это что-то вроде установки маркера в redis, что будет объект типа customer для данного идентификатора, который находится в кеше в ближайшее будущее, которое приводит к блокированию всех других потоков / потоков других экземпляров с целью уменьшения количества внутренних вызовов.

Мой вопрос, существует ли простое или, возможно, нестандартное решение для этого?

Единственное, что я обнаружил, это документы Spring Boot и @Cacheable, что невозможно, поскольку оно синхронизирует вызовы для заданный идентификатор в том же приложении, а не широкий сервис в кластерной среде.

И в дополнение к этому, серверная часть очень медленная (5-10 секунд на вызов), что аннотация @Cacheable уже передана поскольку он начинает запись в кэш, когда возвращается реальный объект @Cachable.

Заранее спасибо, Cheers Alex

// Редактировать: я имел в виду, что @Cachable (sync = true) влияет только на уровень экземпляра, а не распределенный уровень. Поэтому, на самом деле, это не имеет смысла из моего понимания.

1 Ответ

0 голосов
/ 06 февраля 2020

Вы можете попробовать использовать @Cacheable (syn c = true), который гарантирует, что только один поток создает кэш, а все остальные потоки могут получить доступ к кэшу вместо выполнения внутреннего вызова.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...