context.Context propaguje anulację przez hierarchiczne drzewo, gdzie każdy wyprowadzony węzeł utrzymuje odniesienie do swojego rodzica poprzez osadzoną strukturę cancelCtx lub valueCtx. Ta struktura drzewa umożliwia dwukierunkowe śledzenie: rodzice znają swoje dzieci przez mapę chronioną mutexem, podczas gdy dzieci znają swoich rodziców przez bezpośrednie odniesienia. Gdy następuje anulacja, ten projekt pozwala na natychmiastowe przejście od korzenia do liści bez globalnej koordynacji.
Gdy na węźle rodzicielskim wywołana jest cancel(), zdobywa mutex, aby chronić mapę children, przechodzi przez wszystkie zarejestrowane konteksty dziecięce i rekurencyjnie wywołuje ich odpowiednie zamknięcia cancel. Funkcja cancel każdego dziecka zamyka swój własny dedykowany kanał done (przydzielany leniwie za pomocą sync.Once, aby zoptymalizować dla kontekstów, które nigdy nie są anulowane) i usuwa się z mapy children rodzica, aby wyeliminować odniesienia, które w przeciwnym razie uniemożliwiłyby zbieranie śmieci. Ten mechanizm zapewnia, że sygnały anulacji propagują się natychmiastowo przez całe poddrzewo, unikając wycieków zasobów.
W przypadku anulacji opartej na czasie, timerCtx osadza time.Timer, który automatycznie uruchamia zamknięcie cancel, gdy upływa termin. Kluczowo, jeśli rodzic anuluje przed wyzwoleniem timera, funkcja cancel dziecka wyraźnie zatrzymuje timer za pomocą Stop() i opróżnia kanał, jeśli to konieczne, zapobiegając utrzymywaniu się goroutine timera w czasie działania i zużywaniu zasobów po tym, jak kontekst został już anulowany.
Rozważmy mikroserwis Go o dużej przepustowości, który przetwarza zapytania użytkowników skierowane do trzech usług downstream: głównej bazy danych PostgreSQL, pamięci podręcznej Redis i zewnętrznego REST API. Każde zapytanie musi wykonywać zapytania do wszystkich trzech źródeł, aby złożyć odpowiedź, z latencjami p99 planowanymi na poniżej 500 milisekund. Usługa obsługuje tysiące równoczesnych połączeń, co sprawia, że zarządzanie zasobami jest kluczowe dla stabilności.
Opis problemu:
Pod dużym obciążeniem klienci często rozłączają się (przekroczenie limitu czasu lub zamknięcie połączenia) po złożeniu zapytań, ale goroutines ciągle przetwarzają pełne zapytania do bazy danych i czekają na wolne zewnętrzne API, wyczerpując pule połączeń i CPU, mimo że wyniki są bezwartościowe. Ręczna anulacja wymaga przesyłania zmiennych boolowskich przez dziesiątki wywołań funkcji, co jest kruche i skłonne do błędów. Dodatkowo, bez odpowiedniej propagacji, goroutines obsługujące te porzucone zapytania mogą się nieskończenie akumulować, w końcu powodując stan OOM (Out Of Memory) lub wyczerpanie deskryptorów plików na serwerze.
Różne rozważane rozwiązania:
Ręczna propagacja z atomowymi znacznikami: Rozważaliśmy przekazywanie wskaźnika do atomic.Bool przez każdy podpis funkcji, sprawdzając go okresowo w pętlach. To podejście oferuje zerowe narzuty abstrakcji i zapewnia wyraźną kontrolę nad punktami anulacji. Jednak nie może przerwać blokujących wywołań systemowych, takich jak odczyty TCP, wymaga inwazyjnych zmian kodu w każdej funkcji biblioteki i nie oferuje standaryzacji dla limitów czasu ani terminów.
Farma goroutines z explicite kill channels: Uruchomienie każdej operacji downstream w osobnej goroutine i użycie bloku select na niestandardowym kanale zamknięcia pozwala na wczesne zakończenie, gdy żądana jest anulacja. To podejście zapewnia nieblokujące punkty anulacji i modułowe zarządzanie limitami czasu dla każdej operacji. Nadal jednak tworzy O(n) goroutines na zapytanie, gdzie n to liczba operacji, wiąże się z dużymi narzutami na harmonogram i nadal nie może wymusić anulacji w bibliotekach stron trzecich, które nie akceptują kanałów ani nie sprawdzają stanów anulacji.
Standardowa propagacja drzewa kontekstów: Wykorzystanie http.Request.Context() jako korzenia i wyprowadzanie kontekstów dziecięcych za pomocą context.WithTimeout dla każdego wywołania downstream pozwala na natywną obsługę anulacji w standardowej bibliotece. Ta metoda zapewnia automatyczną propagację limitów przez cały stos wywołań bez narzutu goroutines na operacje i automatycznie obsługuje czyszczenie timerów. Wymaga jednak ścisłej zgodności z odpowiednim użyciem API, takiego jak zawsze wywoływanie funkcji anulacji zwracanej przez WithTimeout, aby uniknąć wycieków zasobów timera.
Wybrane rozwiązanie i wynik:
Wybraliśmy standardową propagację drzewa kontekstów, gdzie każdy handler HTTP wyprowadza kontekst o zakresie żądania z 30-sekundowym limitem czasu, a poszczególne zapytania do bazy danych używają context.WithTimeout(reqCtx, 2*time.Second), aby wymusić surowsze podterminy. Gdy klient rozłącza się, serwer HTTP anuluje korzeń kontekstu, który przeszukuje drzewo i natychmiast odblokowuje wywołania sieciowe sterownika sql, aby zwolnić połączenia. W testach obciążeniowych przy 10 tysiącach równoczesnych zapytań i 30% spadku klientów, zdarzenia wyczerpania puli połączeń spadły o 95%, a latencja p99 dla aktywnych zapytań znacznie się poprawiła z powodu zmniejszonej kontestacji zasobów.
Dlaczego anulowany kontekst dziecka musi wyraźnie usunąć się z mapy children swojego rodzica, aby zapobiec wyciekom pamięci?
Wielu zakłada, że rodzic zachowuje dzieci, dopóki sam nie zostanie zniszczony. W praktyce, gdy cancelCtx.cancel() jest wywoływane (czy to z propagacji rodzica, czy lokalnego limitu czasu), zdobywa mutex rodzica i usuwa się z mapy children. Gdyby ta eliminacja nie miała miejsca, długożyjący kontekst rodzica (taki jak kontekst serwera w tle) gromadziłby wpisy dla każdego transitory kontekstu żądania kiedykolwiek utworzonego, uniemożliwiając zbieranie śmieci zakończonej pamięci żądań i powodując nieograniczony wzrost sterty.
Jak context.WithValue osiąga O(1) przestrzeni na klucz, zachowując O(k) czas wyszukiwania, gdzie k to głębokość drzewa, a dlaczego nie używać mapy?
Kandydaci często sugerują kopiowanie mapy przy każdym wywołaniu WithValue (co byłoby O(n) w rozmiarze mapy) lub używanie globalnej zsynchronizowanej mapy (problemy z konkurecją). Rzeczywista implementacja używa listy powiązanej: każdy valueCtx zawiera klucz, wartość i wskaźnik do rodzica. Value() przechodzi w górę, porównując klucze. Ponieważ drzewa kontekstów rzadko mają więcej niż 5-10 poziomów (żądanie → handler → usługa → DB → tx), czas ten jest efektywnie stały. Użycie mapy dla każdego kontekstu wymagałoby albo kopiowania (kosztowne), albo mutowalności (niebezpieczne dla równoległych odczytów).
Jakie jest konkretne zagrożenie związane z przechowywaniem nil w zmiennej interfejsu context.Context i dlaczego context.Background() zwraca nienaładowaną pustą strukturę zamiast nil?
Podczas gdy var c context.Context = nil jest ważne, przekazywanie go do funkcji oczekujących kontekstów możliwych do anulacji powoduje paniki, gdy wywoływane są metody na pustym interfejsie. Background() zwraca pojedynczy backgroundCtx{} (nenaładowaną pustą strukturę implementującą interfejs), aby zapewnić, że wywołania metod zawsze się powiodą i aby zapewnić stabilny korzeń dla drzew kontekstów. To unika pomyłki „pusty interfejs vs pusty konkretny” (gdzie typowy wskaźnik pusty spełnia sprawdzanie != nil, ale działa panikująco przy wywołaniach metod) poprzez zapewnienie, że wartość kontekstu nigdy nie jest pusta, tylko wskaźnik do rodzica może być logicznie pusty.