PHP Academy · Ders

Eşzamansız Mesajlaşma Neden Önemlidir

Kuyrukların üreticileri tüketicilerden nasıl ayırdığını görün.

Eşzamansız Mesajlaşma Neden Önemlidir, CoddyKit'te ücretsiz bir PHP Academy dersidir. Bu, 4 dersinin 1. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, PHP Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. PHP Academy kursu toplamda 4 dersten oluşur.

Asenkron Mesajlaşma Neden Kullanılır

Senkron bir istekte PHP süreciniz e-posta ağ geçitleri, ödeme işlemcileri veya alt hizmetlerle iletişim kurarken engellenir. Yük altında bu durum gecikmenizi ve kullanılabilirliğinizi çağırdığınız her bağımlılığa bağlar. Asenkron mesajlaşma bu zinciri kırar: üretici bir mesajı kuyruğa bırakıp hemen döner; tüketiciler mesajı daha sonra, kendi hızlarında işler.

Bu derste RabbitMQ veya Kafka'ya geçmeden önce düşünmeniz gereken nedeni — bağımlılıkları ayırmayı, tamponlamayı ve teslimat garantilerinin ödünleşimlerini — ele alacağız.

Zamansal ve Uzamsal Ayrıştırma

Bir kuyruk, üreticileri ve tüketicileri iki eksende birbirinden ayırır:

Uzamsal — taraflardan hiçbirinin diğerinin adresini bilmesi gerekmez; yalnızca aracıyı bilirler.
Zamansal — üretici yayın yaptığında tüketici çalışmıyor olabilir; mesaj bekler.

Aşağıdaki senkron sürüm, web isteğini posta sunucusunun çalışma durumuna ve hızına bağlar.

<?php
// Synchronous: the HTTP request blocks on SMTP
function registerUser(string $email): void {
    saveUser($email);
    // If SMTP is slow or down, the user waits or the request fails
    sendWelcomeEmail($email); // 800ms blocking call
    echo "Registered\n";
}

function saveUser(string $e): void { /* ... */ }
function sendWelcomeEmail(string $e): void { usleep(1); }

registerUser('dev@example.com');

Yayınlayın ve Devam Edin

Asenkron sürüm kullanıcıyı kaydeder, bir UserRegistered mesajı yayınlar ve döner. Ayrı bir çalışan e-postayı gönderir. Artık HTTP gecikmesi, SMTP gidiş-dönüş süresine değil, yalnızca yerel aracının hızlı yayınlama işlemine bağlıdır.

<?php
function registerUser(string $email): void {
    saveUser($email);
    // Publish a lightweight event; worker handles email later
    publish('user.registered', json_encode(['email' => $email]));
    echo "Registered (email queued)\n";
}

function saveUser(string $e): void { /* ... */ }
function publish(string $routingKey, string $payload): void {
    echo "-> queued $routingKey: $payload\n";
}

registerUser('dev@example.com');

Yük Dengeleme (Tamponlama)

Trafik artışları düzensizdir; işleme kapasitesi ise sabittir. Bir kuyruk tampon görevi görür: 10.000 mesajlık bir patlamayı emer ve bir çalışan havuzunun bunları sürdürülebilir bir hızda tüketmesini sağlar. Kuyruk olmadan bu artış, veritabanını veya alt hizmet API'sini doğrudan aşırı yüklerdi.

Buna yük dengeleme denir; kararlılık karşılığında gecikmeyi göze alırsınız (mesajlar kısa süre bekleyebilir, ancak hiçbir şey çökmez).

Teslimat Garantileri

Her mesajlaşma sistemi bir teslimat sözü verir. Hangisine sahip olduğunuzu bilin:

En fazla bir kez — gönder ve unut; mesajlar kaybolabilir, ancak asla yinelenmez.
En az bir kez — onaylanana kadar yeniden teslim edilir; yinelemeler mümkündür. Bu, yaygın varsayılandır.
Tam olarak bir kez — kayıp yok, yineleme yok; pahalıdır ve uygulama katmanında çoğu zaman kısmi bir yanılsamadır.

Gerçek sistemlerin çoğu size en az bir kez teslimat sunduğu için tüketiciler aynı mesajı iki kez görmeye dayanıklı olmalıdır.

Yinelenmeye Dayanıklı Tüketiciler

En az bir kez teslimattaki yinelemelerin çözümü idempotentliktir: bir mesajı iki kez işlemek, bir kez işlemekle aynı sonucu üretir. Yaygın teknik, ileti kimliğini benzersiz bir dizinde saklayan bir yineleme ayıklama anahtarı kullanmaktır.

<?php
function handle(array $msg, PDO $pdo): void {
    $pdo->beginTransaction();
    try {
        // Unique constraint on message_id makes the insert the dedup gate
        $stmt = $pdo->prepare(
            'INSERT INTO processed_messages (id) VALUES (?)'
        );
        $stmt->execute([$msg['id']]);
    } catch (PDOException $e) {
        $pdo->rollBack();
        echo "Duplicate {$msg['id']} skipped\n";
        return; // already handled
    }
    chargeCustomer($msg['amount']);
    $pdo->commit();
}
function chargeCustomer(int $a): void {}

Onaylar ve Yeniden Teslimat

Tüketici başarıyı bir onay ile bildirir. Onay vermeden önce çökerse aracı mesajı başka bir tüketiciye yeniden teslim eder. En az bir kez teslimatı mümkün kılan şey budur; ancak bu, bir ack çağrısının yan etkiden sonra gerçekleşen kayıttan sonra gelmesi ve asla önce yapılmaması gerektiği anlamına gelir.

Çok erken onaylarsanız çökme mesajı kaybettirir. Çok geç onaylarsanız ve çökme gerçekleşirse yineleme alırsınız; bunu da idempotentlik katmanınız karşılar.

<?php
// Pseudocode of the consumer contract
function consumeLoop($channel): void {
    while ($msg = $channel->get()) {
        try {
            processSideEffect($msg);   // commit DB write first
            $channel->ack($msg);       // only then ack
        } catch (\Throwable $e) {
            $channel->nack($msg, requeue: true); // let it redeliver
        }
    }
}
function processSideEffect($m): void {}

Sıralama Ücretsiz Değildir

Tüketicileri yatay olarak ölçeklendirdiğinizde kuyruklar genel sıralamayı garanti etmez. Aynı kuyruktan mesaj çeken iki çalışan bunları eşzamanlı işler; bu nedenle B mesajı A mesajından önce tamamlanabilir.

Sıra önemliyse (örneğin hesap bakiyesi değişimlerinde), anahtara göre bölümlendirme yaparak ilişkili tüm mesajların tek bir tüketiciye sırayla gitmesini sağlamalısınız. Kafka bunu bölümlerle yerel olarak yapar; RabbitMQ ile tutarlı bir özete göre yönlendirme yapıp anahtar başına kuyruklar kullanabilirsiniz.

Ölü Mektup Kuyrukları

Bazı mesajlar hiçbir zaman başarıyla işlenemez; örneğin biçimi bozuk yükler veya silinmiş satırlara başvurular. Bunları sonsuza kadar yeniden denemek kuyruğu kilitler; buna zehirli mesaj denir. Çözüm, ölü mektup kuyruğu (DLQ) düzenidir: N başarısız denemeden sonra mesajı yeniden teslim etmek yerine inceleme için ayrı bir yere yönlendirin.

<?php
function consume(array $msg, $channel): void {
    $attempts = ($msg['headers']['x-attempt'] ?? 0) + 1;
    try {
        process($msg);
        $channel->ack($msg);
    } catch (\Throwable $e) {
        if ($attempts >= 5) {
            $channel->deadLetter($msg); // park in DLQ
        } else {
            $channel->republish($msg, ['x-attempt' => $attempts]);
        }
    }
}
function process(array $m): void {}

Kuyruk Ne Zaman Kullanılmamalı (NOT)

Asenkron mesajlaşma gerçek bir işletim maliyeti ekler: çalıştırmanız gereken bir aracı, ürün ekibine açıklamanız gereken nihai tutarlılık ve süreç sınırları arasında daha zor hata ayıklama.

İş yavaş, dalgalı, yeniden denenebilir veya gönderilip unutulabilir olduğunda kuyruğa başvurun. Çağıran tarafın sonuca hemen gerçekten ihtiyaç duyduğu durumlarda (örneğin kullanıcının görmesi gereken kesin bir fiyat için) işlemi senkron tutun; yanıt gerektiren bir çağrıyı kuyruğa koymak yalnızca gecikme ve karmaşıklık ekler.

Kuyruk ve Günlük

Bu düzenlerin temelinde iki genel aracı biçimi vardır ve bu kursun geri kalanında ikisini de kullanacağız:

Bir görev kuyruğu (RabbitMQ), mesaj onaylandığında onu siler. Mesaj başına yönlendirme ve yaşam süresi değerleriyle işleri birbiriyle yarışan tüketicilerden oluşan bir havuza dağıtma konusunda başarılıdır.
Bir işleme günlüğü (Kafka), mesajları saklama süresi boyunca tutar; her tüketici kendi konumunu izleyebilir ve geçmişi yeniden oynatabilir, ayrıca birçok bağımsız tüketici grubu aynı akışı okuyabilir.

İş dağıtımı için kuyruğu, yüksek verimli olay akışları ve yeniden oynatma için günlüğü seçin.

<?php
$useCase = 'replay events for a new analytics service';
$broker = str_contains($useCase, 'replay') || str_contains($useCase, 'stream')
    ? 'Kafka (commit log)'
    : 'RabbitMQ (task queue)';
echo $broker . "\n";

Hızlı Kontrol

Teslimat garantilerini değerlendirme.

Özet

Artık asenkron mesajlaşmanın ardındaki zihinsel modele sahipsiniz:

Kuyruklar uzamsal + zamansal ayrıştırma sağlar ve yük dengeleme için tampon görevi görür.
Sistemlerin çoğu en az bir kez teslimat sunar; bu nedenle tüketiciler idempotent olmalıdır.
Yan etki kaydedildikten sonra onaylayın; hataların yeniden teslimata yol açmasına izin verin.
Sıralama için anahtara göre bölümlendirme gerekir; zehirli mesajlar için DLQ gerekir.
Çağıranın senkron olarak yanıtlanmasına ihtiyaç duyduğu işleri kuyruğa almayın.

Sırada, bunları PHP'de RabbitMQ ile uygulamaya geçireceksiniz.

Sıkça Sorulan Sorular

“Eşzamansız Mesajlaşma Neden Önemlidir” dersi ücretsiz mi?

Evet — “Eşzamansız Mesajlaşma Neden Önemlidir” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve PHP Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. PHP Academy kursu toplamda 4 dersten oluşur.

“Eşzamansız Mesajlaşma Neden Önemlidir” dersinde ne öğreneceğim?

Kuyrukların üreticileri tüketicilerden nasıl ayırdığını görün. PHP Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

PHP Academy öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te PHP Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 1. dersidir.

“Eşzamansız Mesajlaşma Neden Önemlidir” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu PHP Academy dersinde kod yazıp çalıştırabilir miyim?

Evet. Her PHP Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← PHP Academy Sayfasına Dön