Transakcje w ramach klastra Redis to inna historia niż transakcje z Redis Standalone.
TL;DR;
To bardziej problem koncepcyjny dotyczący gwarancji i kompromisów niż kwestia klienta.
Wyjaśnienie
W klastrze Redis konkretny węzeł jest urządzeniem głównym dla jednego lub większej liczby gniazd mieszających, czyli schematu partycjonowania służącego do dzielenia danych między wiele węzłów. W jednym węźle znajduje się jeden skrót, wyliczony z kluczy użytych w poleceniu. Polecenia z wieloma klawiszami są ograniczone do tego samego gniazda skrótu. W przeciwnym razie są odrzucane. Takie konstelacje są nazywane cross-slot.
Transakcje wydają się być rozwiązaniem do wykonywania poleceń do kluczy międzyslotowych, ale w pewnym momencie opuszcza się zakres jednego węzła i do kontynuacji transakcji potrzebny jest inny węzeł. Może tak być, jeśli jeden klucz znajduje się w jednym węźle, a drugi w innym węźle. Nadal nie ma koordynacji transakcji i czasami może to stanowić problem w przypadku problemów z klastrem Redis.
API wysokiego poziomu zapewniające obsługę transakcyjną klastra Redis napotyka wiele problemów i jak dotąd istnieją dwie strategie, jak radzić sobie z transakcjami w klastrze Redis:
Obsługuj transakcje, jeśli wszystkie klucze znajdują się na jednym węźle
Ta opcja umożliwia w pełni funkcjonalne transakcje. Biblioteka klienta jest wymagana do śledzenia węzła, w którym transakcja jest wykonywana, i zabrania kluczy spoza zakresu slotu na czas trwania transakcji. Ponieważ szczelinę można określić tylko za pomocą polecenia zawierającego klucz, klient musi ustawić flagę transakcyjną i już przy pierwszym poleceniu zawierającym klucz należy wydać polecenie MULTI, tuż przed pierwszym poleceniem w ramach transakcji. Ograniczeniem jest tutaj wyraźny wymóg, aby wszystkie klucze znajdowały się w jednym węźle.
Transakcje rozproszone
W takim przypadku wiele transakcji jest uruchamianych na wszystkich węzłach, które dołączają do transakcji rozproszonej. Ta transakcja rozproszona może zawierać klucze ze wszystkich węzłów głównych. Po wykonaniu transakcji biblioteka klienta wyzwala wykonanie transakcji, biblioteka zbiera wszystkie wyniki (aby zachować kolejność wyników poleceń) i zwraca je do wywołującego.
Ten styl transakcji jest przejrzysty dla klienta. Gdy tylko zażądano klucza w określonym węźle, a węzeł nie jest jeszcze częścią transakcji, MULTI wydawane jest polecenie przyłączenia węzła do transakcji. Wadą jest to, że transakcje nie mogą być już warunkowe (WATCH ). Poszczególne transakcje nie mają wiedzy, czy klucz został zmieniony w innym węźle, więc jedna transakcja może zostać wycofana, podczas gdy inne transakcje powiodą się. Brzmi trochę jak zobowiązanie dwufazowe.
Wniosek
Transakcje Redis przypominają atomowe grupowanie poleceń, które można uzależnić. Należy pamiętać, że wykonanie polecenia jest odroczone, ponieważ wyniki odczytu zwracane są w momencie wykonania transakcji, a nie w momencie wydania polecenia.
W przypadku Klastra Redis klienci nie zdecydowali się na strategię globalną. Uruchamianie transakcji w konkretnym węźle klastra Redis jest bezpieczne, ale ograniczasz się do kluczy obsługiwanych przez ten węzeł. Obie możliwe strategie mają właściwości, które mogą być przydatne w niektórych przypadkach użycia, ale mają również ograniczenia.
