Message Queuing & Fault Tolerance 49 okunma

DLQ Yönetimi ve Retry Mekanizmaları

İşlenemeyen mesajların dead letter queue'ya yönlendirilmesi, retry policy'ler, exponential backoff ve zehirli mesaj (poison message) yönetimi ele alınır.

DLQ Yönetimi ve Retry Mekanizmaları

Dead Letter Queue (DLQ) Yönetimi: Hatalı Mesajları Yeniden İşleme ve Zehirli Mesajlarla Başa Çıkma

Mesajlaşma sistemlerinde (RabbitMQ, Azure Service Bus, AWS SQS, Kafka), her mesaj başarıyla işlenemeyebilir. Tüketici (consumer) bir mesajı işlerken bir hata oluşabilir (veritabanı bağlantısı kopabilir, geçici bir ağ sorunu olabilir veya mesajın formatı bozuk olabilir). Bu hataların üstesinden gelmek için gelişmiş bir strateji gereklidir. Aksi halde, hatalı mesajlar sonsuza kadar kuyrukta döner (poison pill) ve tüm sistemi tıkar.

Dead Letter Queue (DLQ - Ölü Mesaj Kuyruğu), işlenemeyen mesajların yönlendirildiği özel bir kuyruktur. Burada bekleyen mesajlar daha sonra manuel olarak incelenebilir, yeniden işlenebilir veya tamamen atılabilir. DLQ, mesajlaşma sistemlerinin dayanıklılığını (resilience) ve hata yönetimini sağlayan temel yapı taşlarından biridir. Bu yazıda, DLQ kavramını, retry (yeniden deneme) politikalarını, exponential backoff (üstel geri çekilme) ve zehirli mesaj (poison message) yönetimini derinlemesine ele alacağız.

1. DLQ (Dead Letter Queue) Nedir?

DLQ, "ölü" veya "işlenemeyen" mesajların toplandığı bir kuyruktur. Bir mesaj aşağıdaki durumlarda DLQ'ya gönderilir:

  • Tüketici, mesajı reddeder (reject / nack) ve requeue parametresini false olarak ayarlar.

  • Mesajın TTL'si (Time-To-Live) dolar ve zaman aşımına uğrar.

  • Kuyruğun maksimum boyutu (queue length) aşılır.

  • Mesaj, tüketici tarafından belirli sayıda (max-retries) başarısız denemeden sonra hala işlenemez.

DLQ'nun amacı:

  • Sistem Kararlılığı: Hatalı mesajların ana kuyruğu tıkamasını engeller.

  • Hata Analizi: Başarısız mesajları inceleyerek hataları tespit etmek.

  • Manuel Müdahale: İşlenemeyen mesajları daha sonra tekrar işleme veya düzeltme imkanı sunar.

2. RabbitMQ'da DLQ Yapılandırması

RabbitMQ, DLQ için x-dead-letter-exchange ve x-dead-letter-routing-key argümanları ile native destek sunar.

Adım 1: Ana Kuyruğu DLQ ile Yapılandırma

csharp

// Ana kuyruğu oluştururken DLQ ayarlarını ekle
var args = new Dictionary<string, object>
{
    { "x-dead-letter-exchange", "dlx_exchange" },        // Hangi exchange'e gönderileceği
    { "x-dead-letter-routing-key", "failed" }            // Routing key
};
channel.QueueDeclare(
    queue: "order_queue",
    durable: true,
    exclusive: false,
    autoDelete: false,
    arguments: args
);

// DLQ için exchange ve kuyruk oluştur
channel.ExchangeDeclare("dlx_exchange", ExchangeType.Direct);
channel.QueueDeclare("dead_letter_queue", durable: true, exclusive: false, autoDelete: false);
channel.QueueBind("dead_letter_queue", "dlx_exchange", "failed");

Adım 2: Tüketici (Consumer) Tarafında DLQ'ya Yönlendirme

csharp

// Tüketici, mesajı reddeder ve requeue = false yaparsa, mesaj DLQ'ya gider
var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
    try
    {
        var body = ea.Body.ToArray();
        var message = Encoding.UTF8.GetString(body);
        // Mesajı işle...
        channel.BasicAck(deliveryTag: ea.DeliveryTag, multiple: false);
    }
    catch (Exception ex)
    {
        // Hata durumunda mesajı reddet ve DLQ'ya gönder
        channel.BasicNack(
            deliveryTag: ea.DeliveryTag,
            multiple: false,
            requeue: false  // false: DLQ'ya yönlendir, true: kuyruğa geri koy
        );
        Logger.LogError(ex, "Mesaj işlenemedi, DLQ'ya gönderildi.");
    }
};

RabbitMQ'da DLQ ile Retry Deseni:

RabbitMQ'nun DLQ'yu birleştirerek retry kuyruğu (yeniden deneme kuyruğu) oluşturabilirsiniz.

  • Ana Kuyruk: İlk işlemin yapıldığı kuyruk.

  • Retry Kuyruğu: Hata oluştuğunda mesajın TTL'li olarak beklediği kuyruk. (TTL dolunca tekrar ana kuyruğa yönlendirilir.)

  • DLQ (Dead Letter Queue): Maksimum retry sayısı aşıldığında mesajın yönlendirildiği kuyruk.

Bu desen, mesajların otomatik olarak yeniden denenmesini ve başarısız olanların DLQ'ya gönderilmesini sağlar.

3. Azure Service Bus'da DLQ Yönetimi

Azure Service Bus, DLQ'yu native olarak destekler. Her kuyruk veya topic, otomatik olarak ilişkili bir DLQ'ya sahiptir. Bir mesaj aşağıdaki durumlarda DLQ'ya gönderilir:

  • Abandon() çağrılırsa ve MaxDeliveryCount aşılırsa.

  • DeadLetter() metodu ile manuel olarak gönderilirse.

  • Zaman aşımı (TTL) dolduğunda.

csharp

// Azure Service Bus ile DLQ kullanımı
await using var client = new ServiceBusClient(connectionString);
var receiver = client.CreateReceiver(queueName, new ServiceBusReceiverOptions
{
    ReceiveMode = ServiceBusReceiveMode.PeekLock
});

var messages = await receiver.ReceiveMessagesAsync(maxMessages: 10, cancellationToken);

foreach (var message in messages)
{
    try
    {
        // Mesajı işle...
        await receiver.CompleteMessageAsync(message);
    }
    catch (Exception ex)
    {
        // Hata durumunda: maxDeliveryCount aşılınca otomatik DLQ'ya gider
        await receiver.AbandonMessageAsync(message); // Retry sayacını artırır
        // veya manuel DLQ'ya göndermek için:
        // await receiver.DeadLetterMessageAsync(message, deadLetterReason: "Hata oluştu.");
    }
}

4. Retry Politikaları ve Exponential Backoff

Mesaj işleme hatasının geçici olabileceğini varsayarak, mesajları yeniden denemek (retry) çoğu senaryoda doğru bir yaklaşımdır.

A. Basic Retry (Sabit Bekleme)
En basit yöntem. Her başarısız denemeden sonra sabit bir süre beklenir ve yeniden denenir.

csharp

// MassTransit veya Polly ile retry
var retryPolicy = Policy
    .Handle<SqlException>()
    .WaitAndRetry(3, retryAttempt => TimeSpan.FromSeconds(2));

B. Exponential Backoff (Üstel Geri Çekilme)
Her başarısız denemeden sonra bekleme süresi üstel olarak artar (2sn, 4sn, 8sn, 16sn...). Bu, sistemi aşırı yüklenmeye karşı korur.

csharp

// Polly ile exponential backoff
var retryPolicy = Policy
    .Handle<SqlException>()
    .Or<TimeoutException>()
    .WaitAndRetry(5,
        retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)),
        onRetry: (exception, timeSpan, retryCount, context) =>
        {
            Logger.LogWarning($"Retry {retryCount} sonra {timeSpan} saniye bekleniyor.");
        }
    );

C. Jitter (Rastgelelik)
Aynı anda çok sayıda mesaj yeniden denendiğinde, tüm tüketiciler aynı anda sistemi yoklayabilir (thundering herd). Jitter, bekleme süresine rastgele bir değer ekleyerek bu etkiyi azaltır.

csharp

var random = new Random();
var retryPolicy = Policy
    .Handle<HttpRequestException>()
    .WaitAndRetry(5,
        retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)) + TimeSpan.FromMilliseconds(random.Next(0, 200))
    );

D. Retry ile DLQ Entegrasyonu
Deneme sayısı (max retry) aşıldığında mesaj DLQ'ya gönderilir.

csharp

public async Task ProcessMessageAsync(Message message, int maxRetryCount = 3)
{
    int attempt = message.Properties.ContainsKey("RetryCount") ? (int)message.Properties["RetryCount"] : 0;

    try
    {
        // Mesajı işle...
        await ProcessAsync(message);
    }
    catch (Exception ex)
    {
        if (attempt < maxRetryCount - 1)
        {
            // Yeniden dene: RetryCount'u artır ve kuyruğa geri bırak
            message.Properties["RetryCount"] = attempt + 1;
            await channel.BasicPublishAsync(...);
        }
        else
        {
            // DLQ'ya gönder
            await channel.BasicNackAsync(..., requeue: false);
            Logger.LogError(ex, $"Mesaj {maxRetryCount} kez denendi, DLQ'ya gönderildi.");
        }
    }
}

5. Zehirli Mesaj (Poison Message) Yönetimi

Poison Message (Zehirli Mesaj), işlenmesi imkansız olan, formatı bozuk veya geçerli olmayan veri içeren mesajdır. Bu mesajlar tekrar tekrar işlenmeye çalışılırsa sonsuz döngüye girebilir ve sistemin performansını düşürebilir.

Zehirli Mesaj Tespiti ve Yönetimi:

  1. Try-Catch ile Yakalama: Mesaj işleme kodunu try-catch ile sarmalayın.

  2. Retry Sayısını Sınırlama: Bir mesajın maksimum kaç kez denenebileceğini belirleyin.

  3. DLQ'ya Yönlendirme: Max retry aşıldığında mesajı DLQ'ya gönderin.

  4. Manuel Müdahale: DLQ'daki mesajları periyodik olarak kontrol edin. Sorunun kaynağını tespit edip düzeltin, mesajı yeniden işleyin veya atın.

RabbitMQ'da Poison Message Handling:
RabbitMQ'da bir mesaj, tüketici tarafından basic.reject veya basic.nack ile requeue=false gönderilirse, direkt DLQ'ya gider. Bu, zehirli mesajların ana kuyruğu tıkamasını engeller.

6. .NET ve MassTransit ile Retry ve DLQ Yönetimi

MassTransit, RabbitMQ ve Azure Service Bus üzerinde retry ve DLQ yönetimini çok kolaylaştırır.

csharp

// MassTransit ile Retry ve DLQ yapılandırması
builder.Services.AddMassTransit(x =>
{
    x.AddConsumer<OrderConsumer>();

    x.UsingRabbitMq((context, cfg) =>
    {
        cfg.Host("localhost", "/", h => { ... });

        cfg.ReceiveEndpoint("order_queue", e =>
        {
            e.ConfigureConsumer<OrderConsumer>(context);
            
            // Retry politikası: 5 kez dene, exponential backoff ile
            e.UseRetry(r => r.Exponential(
                retryLimit: 5,
                minBackoff: TimeSpan.FromSeconds(1),
                maxBackoff: TimeSpan.FromSeconds(30),
                deltaBackoff: TimeSpan.FromSeconds(2)
            ));
        });
    });
});

public class OrderConsumer : IConsumer<OrderMessage>
{
    public async Task Consume(ConsumeContext<OrderMessage> context)
    {
        try
        {
            // Mesaj işleme...
            if (context.Message.IsInvalid)
                throw new InvalidOperationException("Geçersiz mesaj!");

            await context.Publish(new OrderProcessedEvent(context.Message.OrderId));
        }
        catch (Exception ex)
        {
            // Hata fırlatılınca MassTransit retry mekanizmasını tetikler.
            // Max retry aşılırsa, mesaj _error queue (DLQ) gönderilir.
            throw;
        }
    }
}

MassTransit, hata durumunda mesajı otomatik olarak _error (sku) kuyruğuna gönderir. Bu, DLQ görevi görür ve hata detaylarını içerir.

7. DLQ Yönetimi İçin En İyi Pratikler

  1. Zehirli Mesajları İzleyin: DLQ'ya gönderilen mesajların nedenlerini loglayın ve analiz edin.

  2. DLQ'yu Otomatik Boşaltın: Başarısız mesajlar birikmesini önlemek için periyodik olarak temizleyin veya otomatik olarak arşivleyin.

  3. Retry Sayısını İyi Ayarlayın: Çok az retry, geçici sorunlar için yetersizdir. Çok fazla retry ise sistemi yorar.

  4. Ölçeklenebilirlik: DLQ'daki mesajları işlemek için ayrı bir tüketici grubu oluşturun (Consumer Group).

  5. Görünürlük ve Uyarı: DLQ'da mesaj sayısı kritik seviyeye ulaştığında uyarı (alert) gönderecek bir monitoring sistemi kurun.

Sonuç:

Dead Letter Queue (DLQ), mesajlaşma sistemlerinde hata yönetiminin olmazsa olmaz bir parçasıdır. Doğru yapılandırılmış bir DLQ, geçici hataları tolere ederken, zehirli mesajların sistemi tıkamasını engeller. Retry politikaları (özellikle exponential backoff) ve DLQ entegrasyonu ile sisteminizin dayanıklılığını (resilience) önemli ölçüde artırabilirsiniz.

Unutmayın:

  • Retry geçici hatalar içindir.

  • DLQ kalıcı hatalar içindir.

  • Zehirli Mesajlar manuel müdahale gerektirir.

Bu üç mekanizmayı birlikte kullanarak, mesajlaşma sisteminizde maksimum verimlilik ve güvenilirlik elde edebilirsiniz.

Tüm yazılar