Cachowanie, Spring + Hazelcast

Musze skorzystać z cachowania Hazelcast w springu, nie robiłem tego wcześniej, ale przeszukałem kilka artykułów i znalazłem takie rozwiązanie:
https://www.onlinetutorialspoint.com/spring-boot/spring-boot-hazelcast-cache-example.html
Będzie dobre?

Generalnie sytuacja jest prosta, mam mikroserwis X i w trakcie metody chce pobierać pewne dane z mikroserwisu Y. Podczas odpytywania mikroserwisu X chciałem aby dane z mikroserwisu Y były caschowane przez pewien czas, np. kilka dni

Nie znam się, ale wiem że Grzegorz P. opowiada o tym dużo:

Generalnie sytuacja jest prosta, mam mikroserwis X i w trakcie metody chce pobierać pewne dane z mikroserwisu Y. Podczas odpytywania mikroserwisu X chciałem aby dane z mikroserwisu Y były caschowane przez pewien czas, np. kilka dni

Ale po co tu ten hazelcast w takim razie? Hazelcast to jest distributed cache, podobny do redista, więc to co opisujesz ma sens, jesli mówimy tu o replikacji na N nodów. Tzn pobierasz dane z Y i chcesz zeby N instancji serwisu X dostało te dane do swojego cache. O to chodzi?

Bo jeśli masz tu 1:1, to dużo prościej zrobić to w 3 linijkach za pomocą Caffeine.

Wiesz co, hazelcasta już mamy w tym komponencie i chciałem jego użyć (tzn gostek któy jest nade mną, powiedział aby tego użyć skoro to już mamy)

no generalnie chodzi o zaciągnięcie danych z innego mikroserwisu (raz na kilkanaście dni) i wyplucie ich w moim komponencie gdzie będą dalej przetważane

No ok, ale to jest 1:1? Bez replikacji na wiele nodów? To weź nie kombinuj z hazelkastem tylko:

        cache = Caffeine.newBuilder()
                .expireAfterAccess(cacheExpirationDuration)
                .build();

A potem w kodzie jakieś cache.get(key, key -> loadMissing(key)) i cyk, pora na CSa. Bo teraz to walisz z armaty do muchy.

Nie rozumiem do końca replikacji wielu nodów, u mnie zapewne chodzi o sytuacje 1:1. Pobieram obiekt i pracuje na nim

@mariusz00: chodzi o to czy masz kilka instancji tego mikroserwisow...

@mariusz00 no masz mikroserwis X, ale często robi się tak ze ten mikroserwis jest uruchomiony np. na 10 maszynach równolegle i stoi tam jakiś load-balancer który rozdziela między te instancje requesty użytkowników. Wtedy np. taki cache trzeba magicznie zreplikować na każdej z 10 maszyn.

Napisz pozniej na czym stanelo, hazelcast i corpo-drill czy local kesz

Shalom napisał(a):

Bo teraz to walisz z armaty do muchy.

Nie do końca. A konkretnie - nie wiemy, czy to do czego strzelamy to słoń czy mucha. Sam fakt, że mają w projekcie Hazelcasta oznacza, że wypada sprawdzić, czy ichnie problemy nie są problemami trochę bardziej skomplikowanymi

Caffeine jest in-memory. Oznacza to, że przy restarcie JVMki cache musi być odświeżony, co nie jest problemem przy distributed cache.
Ma to kilka implikacji:

• jeśli zewnętrzna usługa jest bezstanowa, ale zmienna (np. 1 stycznia dostajesz A, 2 stycznia już nie możesz dostać A, tylko B) i jednocześnie chcesz przetrzymywać stan z 1 stycznia, potem z 10 stycznia, potem z 20go itp. - to lepiej użyć czegokolwiek nie in-memory
• jeśli koszt wywołania zewnętrznej usługi jest "duży" (tj. wywołanie kosztuje, lub mikroserwis kręci się bardzo długo i blokuje dostęp innym) to lepiej jednak użyć czegoś, co nie jest in-memory

Nie wykluczam, że Caffeine tutaj będzie optymalnym rozwiązaniem. Po prostu w korporacjach różne historie się dzieją i lepiej sprawdzić czy nie ma drugiego dna w tej sprawie.