Düşük gecikme için Disruptor deseni: öngörülebilir gerçek zamanlı tasarım

Gerçek zamanlı uygulamalar kod hızlı olsa neden yavaş hissedilir?\n\nHızın iki yüzü vardır: throughput ve latency. Throughput saniyede ne kadar iş bitirdiğinizdir (istekler, mesajlar, kareler). Latency ise tek bir iş biriminin baştan sona ne kadar sürdüğüdür.\n\nBir sistem müthiş throughput'a sahip olabilir ama bazı istekler çok daha uzun sürüyorsa yine yavaş hissedilir. Bu yüzden ortalamalar yanıltır. Eğer 99 işlem 5 ms sürerken bir işlem 80 ms sürüyorsa, ortalama iyi görünür; ama 80 ms'i yaşayan kullanıcı takılmayı hisseder. Gerçek zamanlı sistemlerde nadir zirveler bütün hikayedir çünkü ritmi bozarlar.\n\nÖngörülebilir gecikme demek sadece düşük ortalamayı hedeflemek değil, çoğu işlemin dar bir aralıkta tamamlanmasını sağlamaktır. Bu yüzden ekipler tail'i (p95, p99) izler. Duraklamalar genellikle orada saklanır.\n\n50 ms'lik bir sıçrama ses ve video uygulamalarında (ses patlamaları), çok oyunculu oyunlarda (rubber-banding), gerçek zamanlı alım-satımda (fiyat kaçırma), endüstriyel izlemede (geç alarm) ve canlı panolarda (sayılarda sıçrama, güvenilmez uyarılar) önemli olabilir.\n\nBasit bir örnek: bir sohbet uygulaması çoğu zaman mesajları hızlı teslim eder. Ama arka planda bir duraksama tek bir mesajın 60 ms gecikmesine neden olursa, yazıyor göstergeleri titrer ve konuşma gecikmeli hissedilir; sunucu ortalamada “hızlı” görünse bile.\n\nGerçek zamanlı hissetmek istiyorsanız daha az sürpriz gerekir, sadece daha hızlı kod değil.\n\n## Gecikme temelleri: zaman gerçekten nerede harcanıyor\n\nÇoğu gerçek zamanlı sistem CPU'nun zorlanmasından yavaş değildir. Yavaş hissetmelerinin nedeni işin çoğunun beklemede geçmesidir: çalıştırılmayı beklemek, bir kuyruğun arkasında beklemek, ağda beklemek veya depolamayı beklemek.\n\nUçtan uca gecikme “bir şey oldu”dan “kullanıcı sonucu gördü”ye kadar geçen tam süredir. Handler'ınız 2 ms çalışsa bile istek beş farklı yerde duraklarsa yine 80 ms alabilir.\n\nYolu şu şekilde bölmek faydalıdır: \n\n- Ağ zamanı (istemciden kenara, servisler arası, yeniden denemeler)\n- Zamanlama (thread'in çalışmayı beklemesi)\n- Kuyruk zamanı (işin diğer işlerin arkasında beklemesi)\n- Depolama zamanı (disk, veritabanı kilitleri, cache miss'ler)\n- Seri hale getirme zamanı (veriyi kodlama/çözme)\n\nBu beklemeler üst üste biner. Burada birkaç milisaniye toplandığında “hızlı” bir yol yavaş bir deneyime dönüşür.\n\nTail gecikme kullanıcıların şikayet etmeye başladığı yerdir. Ortalama gecikme iyi görünse bile p95 veya p99, en yavaş %5 veya %1'i gösterir. Aykırılıklar genellikle nadir duraklamalardan gelir: bir GC döngüsü, host üzerindeki gürültülü bir komşu, kısa süreli kilit içerme, bir cache doldurma veya kuyruğun oluştuğu bir patlama.\n\nSomut örnek: fiyat güncellemesi ağda 5 ms içinde gelir, meşgul bir worker için 10 ms bekler, diğer olayların arkasında 15 ms geçirir, sonra veritabanında 30 ms'lik bir duraklama yaşar. Kodunuz hâlâ 2 ms çalışmış olabilir, ama kullanıcı 62 ms beklemiştir. Amaç her adımı tahmin edilebilir kılmaktır, sadece hesaplamayı hızlı yapmak değil.\n\n## Kod hızının ötesindeki jitter kaynakları\n\nHızlı bir algoritma bile zaman başına düşen süreler dalgalanıyorsa yine yavaş hissedilebilir. Kullanıcılar ortalamayı değil zirveleri fark eder. Bu dalgalanma jitter'dır ve genellikle kodunuzun tamamen kontrolünde olmayan şeylerden gelir.\n\nCPU önbellekleri ve bellek davranışı gizli maliyetlerdir. Sık erişilen veri cache'e sığmazsa CPU RAM'i bekler. Nesne-ağır yapılar, dağınık bellek ve “bir kez daha bir bak” durumları tekrarlayan cache miss'lere dönüşebilir.\n\nBellek tahsisi kendi rastgeleliğini ekler. Kısa ömürlü çok sayıda nesne ayırmak heap üzerinde basınç yaratır; bu daha sonra duraklamalar (garbage collection) veya allocator çatışması olarak görünür. GC olmasa bile sık tahsisler bellek parçalanmasına ve locality kaybına neden olabilir.\n\nThread zamanlaması başka bir yaygın kaynaktır. Bir thread deschedule edildiğinde context switch maliyeti ve cache sıcaklığının kaybı ortaya çıkar. Yoğun bir makinede “gerçek zamanlı” thread'iniz alakasız işlerin arkasında bekleyebilir.\n\nKilit içerme, öngörülebilir sistemlerin sıklıkla çöktüğü yerdir. “Genelde boş” olan bir kilit konvoya dönüşebilir: thread'ler uyanır, kilit için mücadele eder ve birbirlerini tekrar uyuturlar. İş yine yapılır, ancak tail gecikme uzar.\n\nI/O beklemeleri her şeyi gölgede bırakabilir. Tek bir syscall, dolu bir ağ tamponu, TLS el sıkışması, disk flush veya yavaş DNS sorgusu keskin bir sıçrama yaratabilir; hiçbir mikro-optimizasyon bunu tamamen düzeltmez.\n\nJitter avına çıktıysanız, cache miss'lerini (çoğunlukla pointer-ağır yapılar ve rastgele erişim neden olur), sık tahsisleri, çok fazla thread veya gürültülü komşulardan kaynaklanan context switch'leri, kilit içerme ve sıcak yolda bloklayan herhangi bir I/O'yu arayın.\n\nÖrnek: bir fiyat-ticker servisi mikrosaniyelerde güncelleme hesaplayabilir, ama tek bir senkronize logger çağrısı veya içerilmiş bir metrik kilidi ara sıra onlarca milisaniye ekleyebilir.\n\n## Martin Thompson ve Disruptor deseni nedir\n\nMartin Thompson, düşük gecikme mühendisliğinde sadece ortalama hız değil, baskı altındaki sistem davranışına odaklanmasıyla bilinir. LMAX ekibiyle birlikte Disruptor desenini popülerleştirmeye katkıda bulundu; bu desen, olayları küçük ve tutarlı gecikmelerle sistemde taşımak için referans bir yaklaşımdır.\n\nDisruptor yaklaşımı, birçok “hızlı” uygulamayı öngörülemez yapan şeye yanıt olarak ortaya çıktı: içerme ve koordinasyon. Tipik kuyruklar genellikle kilitlere veya yoğun atomik operasyonlara dayanır, thread'leri açıp kapatır ve üreticiler ile tüketiciler paylaşılan yapılar üzerinde rekabet ettiğinde bekleme patlamaları yaratır.\n\nKuyruk yerine Disruptor bir ring buffer kullanır: slotlarda olayları tutan sabit boyutlu bir döngüsel dizi. Üreticiler bir sonraki slotu talep eder, veriyi yazar, sonra bir sıra numarası yayınlar. Tüketiciler bu sırayı takip ederek sıralı şekilde okur. Buffer önceden ayrıldığı için sık tahsislardan kaçınır ve garbage collector baskısını azaltırsınız.\n\nAna fikirlerden biri tek-yazar ilkesidir: paylaşılan bir durum parçasından sorumlu tek bir bileşen tutun (ör. ring boyunca ilerleyen cursor). Daha az yazar “sırada kim var?” anlarını azaltır.\n\nGeri basınç açık ve nettir. Tüketiciler geride kaldığında, üreticiler hâlâ kullanımda olan bir slota ulaşır. O noktada sistem beklemek, düşürmek veya yavaşlamak zorundadır; ama bunu kontrol edilen, görünür bir şekilde yapar, sonsuz büyüyen bir kuyruğun arkasına gizlemek yerine.\n\n## Gecikmeyi tutarlı kılan temel tasarım fikirleri\n\nDisruptor tarzı tasarımları hızlı yapan şey bir mikro-optimizasyon değil; sistemin kendi hareketli parçalarıyla kavga ettiğinde ortaya çıkan öngörülemez duraklamaları ortadan kaldırmaktır: tahsisler, cache miss'ler, kilit içerme ve sıcak yolda karışan ağır işler.\n\nKullanışlı bir zihinsel model montaj hattıdır. Olaylar sabit rota boyunca net el değişimleriyle hareket eder. Bu paylaşılan durumu azaltır ve her adımı basit ve ölçülebilir tutmayı kolaylaştırır.\n\n### Belleği ve veriyi tahmin edilebilir tutun\n\nHızlı sistemler sürpriz tahsislerden kaçınır. Buffer'ları önceden ayırıp mesaj nesnelerini yeniden kullanırsanız, garbage collection, heap büyümesi ve allocator kilitlerinin neden olduğu “bazen” spike'larından kurtulursunuz.\n\nAyrıca mesajları küçük ve sabit tutmak yardımcı olur. Her olayda dokunduğunuz veri CPU cache'ine sığarsa bellek beklemelerinde daha az zaman harcarsınız.\n\nPratikte en önemli alışkanlıklar şunlardır: her olay için yeni nesneler yaratmak yerine nesneleri yeniden kullanın, olay verisini kompakt tutun, paylaşılan durum için tek yazarı tercih edin ve koordinasyon maliyetini daha az sıklıkta ödeyecek şekilde dikkatli batching yapın.\n\n### Yavaş yolları bariz kılın\n\nGerçek zamanlı uygulamalar genellikle loglama, metrikler, yeniden denemeler veya veritabanı yazmaları gibi ekstra ihtiyaçlara sahiptir. Disruptor zihniyeti, bunları çekirdek döngüden izole etmektir, böylece onları engelleyemezler.\n\nCanlı bir fiyat akışında sıcak yol yalnızca bir tick'i doğrulayıp bir sonraki fiyat anlık görüntüsünü yayınlamak olabilir. Disk, ağ çağrıları veya ağır serileştirme gibi duraklatabilecek her şey ayrı bir tüketiciye veya yan kanala taşınır, böylece öngörülebilir yol öngörülebilir kalır.\n\n## Öngörülebilir gecikme için mimari seçimler\n\nÖngörülebilir gecikme büyük ölçüde bir mimari sorunudur. Çok sayıda thread aynı veriyi paylaşırsa veya mesajlar gereksiz yere ağ üzerinde sekip duruyorsa hızlı kodunuzda bile zirveler oluşur.\n\nÖnce kaç yazar ve okuyucunun aynı kuyruk veya buffer'ı etkilediğine karar verin. Tek bir üretici daha düzgün tutmak daha kolaydır çünkü koordinasyondan kaçınırsınız. Çoklu üretici düzenleri throughput'u artırabilir, ancak genellikle içerme ekleyip en kötü durum zamanlamasını daha öngörülemez kılar. Birden çok üreticiye ihtiyaç varsa, paylaşılan yazmaları azaltmak için olayları anahtara göre shard'layın (ör. userId veya instrumentId) böylece her shard'ın kendi sıcak yolu olur.\n\nTüketici tarafında, sıralama önemliyse tek bir tüketici en stabil zamanlamayı verir çünkü durum yerel bir thread'te kalır. İşçi havuzları görevler gerçekten bağımsızsa yardımcı olur, ama zamanlama gecikmeleri ekler ve dikkatli olmazsanız işi yeniden sıralayabilir.\n\nBatching bir başka takastır. Küçük batch'ler overhead'i keser (daha az uyanma, daha az cache miss), ama batch için olayları bekletmek beklemeyi artırabilir. Gerçek zamanlı bir sistemde batch yapıyorsanız bekleme süresini sınırlandırın (örneğin “en fazla 16 olay veya 200 mikro saniye, hangisi önce gerçekleşirse”).\n\nServis sınırları da önemlidir. Sıkı gecikme gerektiğinde işlem içi (in-process) mesajlaşma genellikle en iyisidir. Ölçek için ağ hop'ları gerekliyse karşılığında her hop kuyruklar, yeniden denemeler ve değişken gecikme ekler. Hop gerekiyorsa protokolü basit tutun ve sıcak yolda fan-out'tan kaçının.\n\nPratik bir kural seti: mümkün olduğunda shard başına tek-yazar yolu tutun, bir sıcak kuyruğu paylaşmak yerine anahtarlarla shard'layarak ölçekleyin, batch yaparken kesin bir zaman limiti koyun, sadece paralel ve bağımsız işler için işçi havuzları ekleyin ve her ağ hop'unu ölçene kadar potansiyel bir jitter kaynağı olarak değerlendirin.\n\n## Adım adım: düşük-jitter bir boru hattı tasarlamak\n\nKod yazmaya başlamadan önce yazılı bir gecikme bütçesiyle başlayın. Bir hedef seçin (iyi hissettiren nedir) ve bir p99 belirleyin (altında kalmanız gereken sınır). Bu sayıyı girdi, doğrulama, eşleştirme, kalıcılık ve dışa güncellemeler gibi aşamalara bölün. Bir aşamanın bütçesi yoksa sınırı yoktur.\n\nSonra tam veri akışını çizin ve her el değişimini işaretleyin: thread sınırları, kuyruklar, ağ hop'ları ve depolama çağrıları. Her el değişimi jitter'in saklanabileceği yerdir. Gördüğünüzde, azaltabilirsiniz.\n\nTasarımı dürüst tutacak bir iş akışı: