Laravel Bekleyen İstek – DEV Community

Problem

Arka planda bazı verileri işlerken, ilgili verileri okumak için başka bir istek yapılmış olabilir. Bu durumda ya tarihsel bir veri sağlıyorsunuz ya da hatalı bilgi sunuyorsunuz.

Çözüm

İşlem tamamlanana kadar isteği bekletmek, en basit çözüm olabilir. Bu benim tek çözüm önerim değil, fakat en basiti.

Bazı Senaryolar

Olası senaryolar hakkında konuşalım.

Rezervasyon İşlemi

Kullanıcı, iki belirli tarih arasında bir kaynağı rezerve etmek istediğinde, bunun bir iş aracılığıyla yapıldığını varsayalım. Üretim yükü dolayısıyla bu işlem bir süre alabilir. Bu esnada, başka bir istek kullanıcının rezervasyon verilerini sorguluyorsa, ne olmalı?

Dosya Yükleme İşlemi

Kullanıcı, bir CSV veya XML dosyası yüklediğinde, dosyayı kabul ettiniz fakat işlemenin de yapılması gerekiyor, bu bir işte gerçekleşmeli. Kullanıcı, başka bir istekte CSV kaynağının durumunu sorarsa ne olacak?

Paket

aihimel/laravel-waiting-request tam olarak bunu çözen küçük bir Laravel paketidir —bu paket, bir isteğin, başka bir işlem (bir iş, senkronizasyon veya uzun süreli kontrolör eylemi) kaynağın okunmaya hazır olduğunu belirttiği ana kadar beklemesine olanak tanır.

Kurulum

composer require aihimel/laravel-waiting-request

Opsiyonel olarak konfigürasyonu yayınlayın:

php artisan vendor:publish --tag="waiting-request-config"

Nasıl Çalışır

Paket, dört fikir etrafında küçük bir API sunar: block, wait, check, resolve. Temelde Laravel önbelleği ile çalışır — fazla bir altyapıya veya kuyruk sistemine ihtiyaç duymaz.

Bir engelleyici, bir sınıf yolu ve bir kaynak id ile tanımlanır. Bu çift, benzersiz bir önbellek anahtarı oluşturur, böylece engelleyiciler kaynak başına (rezervasyon 42 diğer rezervasyon 43 ile çakışmaz) olur.

use Aihimel\LaravelWaitingRequest\Facades\LWRequest;

// 1. Block — arka plan işinin başladığı yerde çağırın
LWRequest::addBlocker(Booking::class, $booking->id);

// 2. Wait — kaynağı okumak isteyen istekte çağırın
$resolved = LWRequest::whenResolved(Booking::class, $booking->id);
if ($resolved) {
    return BookingResource::make($booking->fresh());
}
return response()->json(['message' => 'Hala işleniyor, tekrar deneyin'], 202);

// 3. Resolve — arka plan işi bittiğinde çağırın
LWRequest::resolveBlocker(Booking::class, $booking->id);

Ayrıca beklemeden göz atabilirsiniz:

if (LWRequest::isBlocked(Booking::class, $booking->id)) {
    // kaynak işleniyor
}

Senaryolara Uygulanması

Rezervasyon işlemi. Rezervasyonu kabul eden kontrolör, addBlocker(Booking::class, $id) çağırarak işi başlatır. İş, handle() içinde resolveBlocker(...) çağrısını yapar. Bu süreçte GET /bookings/{id} isteğini yapan herhangi bir okuyucu ilk olarak whenResolved(...) çağrısını yapar ve yalnızca yazıcı işlemi tamamlandıktan sonra modeli okur.

Dosya yükleme işlemi. Aynı şekilde: yükleme kabul edildiğinde addBlocker(Import::class, $import->id) çağrılır, ayrıştırıcı tamamlandığında resolveBlocker(...) çağrılır (başarı veya başarısızlık — her ikisi de serbest kalmalıdır). Durum uç noktası whenResolved(...) çağrısını yapar, böylece istemci yarım kalmış bir görüntü yerine belirlenmiş bir cevap alır.

Ayarlanabilir Mantıklı Varsayılan Değerler

Her ayar config/waiting-request.php dosyasında bulunur ve .env dosyası üzerinden değiştirilebilir:

addBlocker() isteğe bağlı bir üçüncü argüman alır, böylece belirli bir işin daha uzun sürdüğü zaman TTL’yi artırabilirsiniz:

LWRequest::addBlocker(Import::class, $import->id, 120); // 2 dakika

Neden Engelleyicinin Bir Süresi Var?

Bir iş resolveBlocker() çağırmadan çöküyorsa, okuyucuların sonsuza kadar beklemesini istemezsiniz. Versiyon v2.x’den itibaren her engelleyici bir Unix zaman damgası taşır. O zaman damgasından sonraki isBlocked() / whenResolved() çağrısı:

1. Önbellek girdisini unutacaktır, ve
2. Log::warning('Waiting-request blocker expired without being resolved', [...]) kaydını çıkaracaktır.

Bu nedenle, işiniz çökse bile, trafik kendiliğinden toparlanır ve bunun olduğu konusunda bir kayıt alırsınız.

Yapılması ve Yapılmaması Gerekenler

Yapılacaklar

• Engelleyiciyi finally içinde serbest bırakın. İş gövdesini sarmalayın, böylece fırlatılan bir istisna resolveBlocker()‘a ulaşır. Otomatik süresi dolması bir yedek, hoş bir yol değildir.
• max_blocking_time‘ı en kötü senaryo iş sürenizi aşacak şekilde ayarlayın. Eğer yüklemeniz ortalama 8sn sürüyorsa ve en kötü durumda 25sn alıyorsa, 10sn’lik bir varsayılan süre işin hala devam ederken otomatik olarak serbest bırakılacaktır — bu durumu geçersiz kılar.
• timeout‘ı kullanıcı deneyimi bütçenize uygun şekilde ayarlayın. Eğer bir istemci senkronize cevap için 2sn beklemeyi kabul ediyorsa, timeout=2 ayarlayın; whenResolved()‘ın bir HTTP işçisini 30sn bağlamasına izin vermeyin.
• 1.x’den 2.x’e güncellerken önbelleği temizleyin. Önceki değerler true olarak saklandığında, bunlar 1 olarak okunacak ve zaten süresi dolmuş olarak işlenecek, bu nedenle bir kerelik uyarı günlükleri üretecektir.
• Bir false döndüğünde whenResolved()‘i “henüz bekliyor” olarak değerlendirin. Bununla birlikte 202 Accepted (veya benzeri) olarak yanıt verin ve istemcinin sorgulamasına izin verin — verilerin hazır olduğunu iddia etmeyin.

Yapılmaması Gerekenler

• Beklenmeyen isBlocked() çağrılarını yüksek, yalnızca okuma yollarında yapmayın. Bu, süresi dolmuş öğeleri geçersiz kılar ve bir günlük kaydı oluşturur. Bu kasıtlıdır, ancak bilinmesi gerekir.
• Yazmalar için dağıtılmış bir mutex olarak kullanmayın. Bu paket, yazıcılara bağlı okuyucular için en iyi çaba ile hazırlanmıştır. İki yazar aynı anda sahneye çıkarsa, Cache::add() ikinci addBlocker() çağrısını reddedecektir (bu false döner), ancak paket kuyruklama, adalet veya katı karşılıklı hariç tutma sağlamaz.
• İlgisiz kaynaklar arasında tek bir engelleyici paylaşmayın. Gerçek kaynakla anahtarlandırın (Booking::class + $id), kullanıcı kimliği gibi kaba bir yapı ile değil, yoksa hiçbir ilgisi olmayan istekleri engelleyebilirsiniz.
• Önbellek sürücüsünün önemli olduğunu unutmayın. array veya file sürücüleri süreçler arasında çalışmaz. Üretimde, hem engelleyiciyi çözen işçi hem de bekleyen web işleminin aynı önbelleği paylaşması için redis / memcached kullanın.
• Bir kuyruk işçisinden whenResolved() ile beklemeye güvenmeyin. Bir işçi içinde anket yapmak, bir işçi slotunu harcar. İşçiler, engelleyicileri çözmeli, bunlar üzerinde beklememelidir.

Paketin tamamı — birkaç facade çağrısı, her kaynak için bir önbellek anahtarı ve kimsenin sıkışmasına neden olmayacak mantıklı bir süresi ile birlikte. Eğer daha önce bir ?retry=true hilesi ya da bir kontrolörde bekleyip dua ettiyseniz, bu, onun daha temiz versiyonudur.

Kaynak & sorunlar: github.com/aihimel/laravel-waiting-request