Bir context.Context, her türetilmiş düğümün, gömülü bir cancelCtx veya valueCtx yapısı aracılığıyla, üst düğümüne bir referans tuttuğu hiyerarşik bir ağaç üzerinden iptali yayar. Bu ağaç yapısı, çift yönlü takip etmeyi sağlar: üst düğümler, bir mutex ile korunmuş bir harita aracılığıyla çocuklarını tanırken, çocuklar doğrudan işaretçi referansları aracılığıyla üst düğümlerini tanır. İptal gerçekleştiğinde, bu tasarım, kökten yapraklara hemen geçiş yapılmasını sağlar ve küresel koordinasyona gerek kalmadan.
Üst düğümde cancel() çağrıldığında, children haritasını korumak için bir mutex alır, kayıtlı tüm çocuk bağlamlar üzerinde döner ve ilgili cancel kapatıcılarını özyinelemeli olarak çağırır. Her çocuğun cancel fonksiyonu, kendi özel done kanalını kapatır (iptal edilmeyen bağlamlar için optimize etmek amacıyla sync.Once aracılığıyla tembel bir şekilde ayırır) ve kendisini üst düğümün children haritasından kaldırarak çöp toplayıcıyı engelleyen referansları ortadan kaldırır. Bu mekanizma, iptal sinyallerinin tüm alt ağaçta anında yayılmasını sağlarken kaynak sızıntılarını önler.
Zaman aşımına dayalı iptaller için, timerCtx bir time.Timer içerir ve son tarih sona erdiğinde cancel kapatıcıyı otomatik olarak tetikler. Önemli olan, üst düğüm zamanlayıcı tetiklenmeden önce iptal ederse, çocuğun cancel fonksiyonu, zamanlayıcıyı kesin olarak durdurur ve gerekirse kanalı boşaltır; bu, zamanlayıcı goroutine'inin çalışma zamanında kalmasını ve bağlam zaten iptal edilmişken kaynak tüketimini önler.
Yüksek hacimli bir Go mikroservisini düşünün, kullanıcı isteklerini üç aşağı hizmete yönlendiren: birincil PostgreSQL veritabanı, bir Redis önbelleği ve üçüncü taraf bir REST API. Her isteğin, yanıtı toplamak için tüm üç kaynak üzerinde sorgular yürütmesi gerekiyor; p99 gecikmeleri 500 milisaniye altında olmalıdır. Hizmet binlerce eşzamanlı bağlantıyı yönetiyor, bu da kaynak yönetimini kararlılık için kritik hale getiriyor.
Sorun tanımı:
Ağır yük altında, istemciler sıklıkla bağlantıyı kesiyor (zaman aşımı veya bağlantıyı kapatma) fakat goroutine'ler, veritabanında tam sorguları işlemeye ve yavaş dış API'leri beklemeye devam ediyor, bağlantı havuzlarını ve CPU'yu tüketiyordu, sonuçlar değerli olmasına rağmen. Manuel iptal, bir dizi işlev çağrısı aracılığıyla boolean bayraklarını geçirmek gerektirdiğinden, hassas ve hata yapmaya açıktır. Ayrıca, uygun yayılım olmaksızın, bu terkedilmiş istekleri yöneten goroutine'ler sonsuz birikim yapabilir, sonunda ana sunucuda OOM (Bellek Dışı) durumu veya dosya tanımlayıcı tükenmesine neden olabilir.
Düşünülen farklı çözümler:
Atomik bayraklarla manuel yayılım: Her işlev imzasına bir atomic.Bool işaretçisi geçirmeyi ve döngülerde aralıklarla kontrol etmeyi düşündük. Bu yaklaşım sıfır soyutlama yükü sunuyor ve iptal noktaları üzerinde açık kontrol sağlıyor. Ancak, TCP okumalar gibi engelleyici sistem çağrılarını kesemez, her kütüphane işlevine işgalci kod değişiklikleri gerektirir ve zaman aşımı veya son tarihler için standartlaştırma sunmaz.
Açık öldürme kanalları ile goroutine çiftliği: Her alt akış işlemini ayrı bir goroutine içinde başlatmak ve özel kapanış kanalında bir select bloğu kullanmak, iptal talep edildiğinde erken dönüş sağlar. Bu yaklaşım engellemeyen iptal noktaları ve her operasyon için modüler zaman aşımı yönetimi sağlar. Ancak, her istek başına O(n) goroutine'ler oluşturur; burada n, işlem sayısıdır, önemli zamanlama yükleri getirir ve hala kanalları veya iptal durumlarını kontrol etmeyen üçüncü taraf kütüphanelerin içinde iptal zorlayamaz.
Standart bağlam ağaç yayılımı: Kök olarak http.Request.Context() kullanmak ve her alt akış çağrısı için context.WithTimeout yoluyla çocuk bağlamlar türetmek, standart kütüphanede yerel iptal desteği sağlar. Bu yöntem, tüm çağrı yelpazesi boyunca son tarihlerin otomatik yayılımını sunar; her işlem başına goroutine yükü olmadan ve zamanlayıcı temizliğini otomatik olarak yönetir. Ancak, zamanlayıcı kaynaklarının sızdırılmaması için her zaman WithTimeout tarafından döndürülen iptal işlevini çağırma gibi doğru API kullanımına sıkı bir şekilde uyulmasını gerektirir.
Seçilen çözüm ve sonuç:
Her HTTP işleyicisinin 30 saniyelik bir zaman aşımı ile istek sınırına göre bir bağlam türettiği standart bağlam ağaç yayılımını seçtik ve her bireysel veritabanı sorgusu için context.WithTimeout(reqCtx, 2*time.Second) kullanarak daha sıkı alt son tarihler uyguladık. Bir istemci bağlantıyı kestiğinde, HTTP sunucusu kök bağlamı iptal eder; bu, ağaç boyunca geçiş yapar ve sql sürücüsünün ağ çağrılarını hemen engeller, bağlantıları serbest bırakır. 10k eşzamanlı istek ve %30 istemci düşüşüyle yük testleri altında, bağlantı havuzunun tükenmesi olayları %95 oranında azaldı ve aktif istekler için p99 gecikme, kaynak çatışmalarının azalması sayesinde önemli ölçüde iyileşti.
İptal edilen bir çocuk bağlamının, bellek sızıntılarını önlemek için neden üst bağlamını children haritasından açıkça kaldırması gerekir?
Birçok kişi, üst bağlamın çocukları kendi yok edilene kadar tutacağını varsayıyor. Pratikte, cancelCtx.cancel() çalıştığında (ister üst yayılım veya yerel zaman aşımı olsun), üst düğümün mutex'ini alır ve kendisini children haritasından siler. Bu kaldırma gerçekleşmezse, uzun ömürlü bir üst bağlam (bir arka planda çalışan sunucu bağlamı gibi), oluşturulan her geçici istek bağlamı için girişler biriktirir, tamamlanan istek belleğinin çöp toplayıcısından kaçınmasına neden olur ve sınırsız yığın büyümesine yol açar.
context.WithValue nasıl O(1) anahtar başına alan elde ederken O(k) arama süresini korur, burada k ağaç derinliğidir ve neden bir harita kullanılmıyor?
Adaylar çoğunlukla her WithValue çağrısında bir harita kopyalamayı (bu harita boyutunda O(n) olur) veya küresel bir senkronize harita kullanmayı öne sürerler (eşzamanlılık sorunları). Gerçek uygulama bir bağlı liste kullanır: her valueCtx, bir anahtar, değer ve üst işaretçi içerir. Value(), anahtarları karşılaştırarak yukarı doğru geçiş yapar. Bağlam ağaçları genellikle 5-10 seviyeden daha derin olmadığından (istek → işleyici → hizmet → DB → tx), bu etkili bir şekilde sabit bir zaman olur. Her bağlam için bir harita kullanmak, ya kopyalama (maliyetli) ya da değişkenlik (eşzamanlı okumalar için güvensiz) gerektirir.
context.Context arayüz değişkeninde nil saklamanın özel tehlikesi nedir, ve neden context.Background() nil yerine nil olmayan bir boş yapı döndürür?
var c context.Context = nil geçerli bir ifadedir, ancak bunu iptal edilebilir bağlamlar bekleyen işlevlere geçirmek, nil arayüzü üzerinde yöntemler çağrıldığında paniklere neden olur. Background(), yöntem çağrılarının her zaman başarılı olmasını sağlamak ve bağlam ağaçları için kararlı bir kök sağlamak amacıyla bir singleton backgroundCtx{} (bir nil olmayan boş yapı) döndürür. Bu, "nil arayüzü ile nil somut" karışıklığını önler (türlü bir nil işaretçisinin != nil kontrollerini karşılamasına ama yöntem çağrılarında panik yapmasına neden olur) ve bağlam değerinin asla nil olmamasını garanti eder; yalnızca üst işaretçi mantıken nil olabilir.