Jak w tytule postanowiłem pierwszy raz w życiu zaimplementować cache w aplikacji rozproszonej. Architektura wygląda następująco: mam 1 instancję bazy danych i wiele instancji samej aplikacji, które trzymają wynik zapytania SQL dla podanych argumentów zaś w przypadku gdy robimy jakikolwiek DML wykonujemy flush i pobieramy nowy wynik zapytania. Problem w tym, że wóczas pozostałe instancje nie będą wiedziały o zmianie i będzie musiał upłynąć ustawiony TTL aby odświeżyły cache. Pytanie - w jaki sposób wymusza się wówczas odświeżanie cache? A może istnieje inna droga?
0
1
Jaki masz cache? Bo zazwyczaj jest tak, że cache jest wspólny tak samo jak zwykła baza danych, czy mówisz tu o cache w samej aplikacji (in memory jakiś lokalny)?
3
Czemu nie użyjesz jakiegoś gotowca jak Redis? https://cloudificationzone.com/2021/11/01/distributed-caching-with-redis/
0
Możesz zastosować pattern subscribera, żeby do innych serwisów rozglaszać, że nastąpiła aktualizacja bazy i dane serwisy z cache podmienią dane.
Ale też nie wiem cache czego robisz?
Cache praktycznie wszędzie się stosuje takie to narzędzie wszechstronne, graph wiele razy przechodzisz te same ścieżki i procesor często te same dane wielokrotnie odczytuje.
Musisz też podać architekturę i czy serio chcesz od zera robić takie coś czy z narzędzi skorzystać redis jest w miarę spoko, a tak na strukturach danych musisz polegać.
1
Flow może wyglądać tak:
- instancje cache'a wybierają sobie mastera (tzw. leader election)
- każda oddzielna instancja wysyła informację o zmianie do mastera, master pilnuje o tym, żeby powiadomić resztę instancji o zmianie
- to, czy instancje sobie odświeżają cache czy nie zależy oczywiście od ustawień - czasem jest tak, że cache będzie trzymał stare dane dopóki nikt go o to nie zapyta, czasem master rozsyła nowe wiadomości, a czasem po otrzymaniu info o zmianie instancja podbija gdzieśtam
Druga opcja to wspomniany już publish-subscribe, ale musiałbyś implementować własną kolejkę (co sprowadziłoby się faktycznie do pracy z punktu poprzedniego). Chyba, że dopuszczasz użycie jakiegoś gotowego rozwiązania - wtedy po prostu wszyscy wrzucają zmiany na kolejkę i zczytują zmiany z kolejki.
0
wartek01 napisał(a):
Flow może wyglądać tak:
- instancje cache'a wybierają sobie mastera (tzw. leader election)
- każda oddzielna instancja wysyła informację o zmianie do mastera, master pilnuje o tym, żeby powiadomić resztę instancji o zmianie
- to, czy instancje sobie odświeżają cache czy nie zależy oczywiście od ustawień - czasem jest tak, że cache będzie trzymał stare dane dopóki nikt go o to nie zapyta, czasem master rozsyła nowe wiadomości, a czasem po otrzymaniu info o zmianie instancja podbija gdzieśtam
Druga opcja to wspomniany już publish-subscribe, ale musiałbyś implementować własną kolejkę (co sprowadziłoby się faktycznie do pracy z punktu poprzedniego). Chyba, że dopuszczasz użycie jakiegoś gotowego rozwiązania - wtedy po prostu wszyscy wrzucają zmiany na kolejkę i zczytują zmiany z kolejki.
Właśnie takich komplikacji chciałbym uniknąć. Wydaje mi się, że wpadłem na klasyczny XY problem wynikający z mojej niewiedzy na temat rodzajów cache. Znalazłem na stackoverflow wątek który chyba wyjaśnia moje pytanie (https://stackoverflow.com/questions/38056786/in-memory-cache-vs-centralized-cache-in-a-distributed-system). Zadając pytanie miałem w głowie klasyczną hashmapę (używam tutaj nazwy struktury danych żeby nie zagłębiać się w konkretne technologie) czyli in-memory cache, zaś wygląda na to że potrzebne mi będzie distributed cache. To chyba kończy wątek. Dzięki za pomoc wszystkim :)
0
Użyj gotowego rozwiązania jak Redis, ewentualnie dodatkowo in-memory cache z bardzo krótkim TTL. Zaimplementowanie solucji po stronie aplikacji będzie wymagało dużo gimnastyki i może nie być warte zachodu