Наличие значений ключа кэша Hazel-cast на всех узлах / член - PullRequest
Новая
       16

Наличие значений ключа кэша Hazel-cast на всех узлах / член

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

Я использую hazelCast для кэширования данных, получаемых из API. Структура API выглядит примерно так: 

Controller->Service->DAOLayer->DB

Я держу @Cacheable на сервисном уровне, где присутствует метод getData (int elementID).

В моей архитектуре есть два узла PaaS ( np3a, np4a). API будет развернут на обоих из них, и пользователи будут получать к ним доступ через IP-адрес loadBalancer, который перенаправит их на любой из узлов.

Таким образом, возможно, что для одного обращения пользователя X запрос перейдет к np3a и для другого попадания от того же самого пользовательского запроса идет к np4a.

Я хочу, чтобы в самом первом попадании, когда я кэшировал ответ на np3a, такой же кэшированный ответ также был доступен для следующего попадания на np4a.

Я читал о

  1. ReplicatedMaps : недостаточно памяти
  2. NearCache : при чтении> запись

Я не уверен, какой из подходов выбрать или вы предлагаете что-то совершенно другое.

1 Ответ

1 голос
/ 03 февраля 2020

Если у вас есть 2 узла, Hazelcast разделит данные так, что половина из них будет на узле 1, а другая половина - на узле 2. Это означает, что есть 50% шанс, что пользователь спросит узел, содержащий данные.

Если во всех случаях вы хотите избежать дополнительного сетевого запроса на выборку данных, которых нет на узле, единственный способ - это копировать данные каждый раз на каждый узел. Это цель ReplicatedMap. Это компромисс: производительность и потребление памяти.

NearCache добавляет дополнительный кэш на «стороне клиента», если вы используете архитектуру клиент-сервер (в отличие от встроенной).

...