Cała oryginalna treść jest tworzona po ukraińsku. Nie wszystkie treści zostały jeszcze przetłumaczone. Niektóre posty mogą być dostępne tylko po ukraińsku.Dowiedz się więcej
W rozwoju systemów rozproszonych błędy to nie wyjątek, a norma. Sieć może się zawiesić, usługa - tymczasowo upaść, baza - odmówić na sekundę. I w tym momencie pojawia się proste, ale niebezpieczne pytanie: jak dokładnie powtarzać zapytanie? Jeśli zrobisz to tak samo, system łatwo sam się zniszczy.
Właśnie tutaj pojawiają się opóźnienie eksponencjalne (exponential backoff) i losowy jitter (random jitter).
Exponential Backoff
Exponential Backoff to strategia ponownych prób, w której każda następna próba (retry) odbywa się z coraz większym opóźnieniem. Idea jest bardzo prosta: jeśli coś się zepsuło, nie warto od razu ponownie pukać do tych samych drzwi. Pierwsza próba może być niemal natychmiastowa, druga - po sekundzie, trzecia - po dwóch, potem cztery, osiem i tak dalej. Opóźnienie rośnie eksponencjalnie.
To daje systemowi czas na "złapanie oddechu". Jeśli usługa jest tymczasowo przeciążona lub upada z powodu szczytowego obciążenia, exponential backoff zmniejsza nacisk, a nie go zwiększa. Bez tej strategii klienci zaczynają masowo próbować ponownie w tym samym czasie, a nawet zdrowa usługa może nie wytrzymać takiego naporu.
Jednak tutaj jest podstępny moment. Wyobraź sobie tysiąc klientów, którzy jednocześnie otrzymali błąd i używają takiej samej formuły backoff. Wszyscy będą czekać jedną sekundę, potem dwie, potem cztery - i znów razem uderzą w serwer. Powstaje zsynchronizowany tłum, który przychodzi falami. To już znany problem - efekt "thundering herd".
Dlatego do exponential backoff prawie zawsze dodaje się losowy jitter (random jitter). Jitter to małe losowe przesunięcie w opóźnieniu. Zamiast czekać dokładnie 4 sekundy, klient może poczekać 3.2, inny - 4.7, jeszcze ktoś - 2.9. Wszystkie te same opóźnienia eksponencjalne są zachowane, ale zapytania nie przychodzą już jednocześnie.
Z jitterem system zaczyna działać "żywiej" i stabilniej. Obciążenie rozkłada się w czasie, usłudze łatwiej się odbudować, a prawdopodobieństwo ponownego upadku z powodu masowych prób ponownych znacznie maleje. To szczególnie ważne dla API, kolejek, pracowników zadań i wszelkich integracji z zewnętrznymi usługami.
W rezultacie exponential backoff odpowiada na pytanie "kiedy powtarzać?", a jitter - "jak zrobić to niezsynchronizowane z wszystkimi innymi? Razem tworzą podstawową architekturę dla niezawodnych systemów. Jeśli masz retry bez backoff - to czerwony flag. Jeśli jest backoff bez jittera - żółty. A gdy są oba, system ma znacznie większe szanse przetrwać rzeczywiste, a nie laboratoryjne awarie.