Jak już ustaliliśmy w poprzednich wpisach, jedną z głównych zalet replikacji jest skalowanie liczby zapytań, ma to jednak sens tylko wtedy, gdy replikacja odbywa się asynchronicznie. Innymi słowy, klient nie czeka, aż zapis danych spropaguje się na wszystkie repliki.
Wyobraź sobie następujący scenariusz. Wysyłasz formularz na stronie internetowej, dane trafiają na jeden z węzłów, otrzymujesz komunikat o poprawnym zapisie. Jeśli przeładujesz od razu stronę, odczyt może trafić na inny węzeł. Czy zobaczysz swoje zapisane dane? Tylko w sytuacji kiedy zdążyły się one spropagować pomiędzy repliką, na którą pisałeś, a repliką, z której czytasz. Kiedy system działa na granicy wydajności albo występują problemy sieciowe, lag ten może wynieść nawet kilka sekund. Zjawisko to nosi nazwę eventual consistency.
To, czy zaakceptujesz w swojej aplikacji taki przejściowy stan rzeczy, zależy od domeny i przypadku użycia. Dla rozwiązań HFT (high frequency trading) raczej nie będzie to najlepszy wybór, natomiast w celu dodania profilówki może już będziesz skłonny zaakceptować taką anomalię.
Jeśli nie chcemy rezygnować z asynchronicznej replikacji, ale uniknąć eventual consistency, możemy na przykład rozwiązać to na warstwie aplikacyjnej, dodając routing dla poszczególnych przypadków. Wystarczy, że zapis i odczyt będzie z tej samej repliki. Kiedy na przykład użytkownik pyta o swoje dane, to będą serwowane z repliki, która przyjmuje write’y od niego.
Źródła
Udostępnij ten wpis
Dobrnąłeś do końca. Jeśli ten artykuł był dla Ciebie wartościowy i chcesz otrzymywać informacje o kolejnych, to zapraszam Cię do zapisania się do listy mailingowej. Gwarantuję zero spamu.
Radek.
Inne artykuły
One thought on “Problemy asynchronicznej replikacji [Replikacja 5/5]”
Comments are closed.