2016-03-22 26 views
1

Ich habe aktive Warteschlange, die alle Nachrichten von Publisher haben wird. Mein Consumer liest diese Nachrichten und Acks/Nacks abhängig vom Ergebnis der Nachrichtenverarbeitung.RabbitMQ - So konfigurieren Sie bedingte DLX?

while (true) 
{ 
    var ea = (BasicDeliverEventArgs)consumer.Queue.Dequeue(); 

    var body = ea.Body; 
    var message = Encoding.UTF8.GetString(body); 

    var processed = ProcessMessage(message) 

    if (processed)       
     channel.BasicAck(deliveryTag: ea.DeliveryTag, multiple: false); 
    else 
     channel.BasicNack(deliveryTag: ea.DeliveryTag, multiple: false, requeue: true); 
} 

Meine Fragen sind

  • true für requeue Parameter wird eingestellt wird, wenn es richtig nacked ist?
  • Oder müssen wir eine andere Warteschlange für Retry erstellen?
  • Sagen wir, wenn ich die Nachricht nach 10-maligem Versuch nach DLX verschieben möchte? Wie mache ich es? Ist es C# -Code oder kann eine Regel in der Warteschlange definiert werden?
  • Woher weiß ich, dass eine Nachricht 10 Mal wiederholt wird? Bietet RabbitMQ einen Mechanismus oder muss ich das Nachrichtenobjekt manuell so entwerfen, dass es die Anzahl der Wiederholungen enthält?

Dank für Ihre Eingaben

Antwort

1

wenn Sie Requeue auf false gesetzt, dann wird es in jedem DeadLetter Exchange Queue zugeordnet gehen. True wird die Nachricht zurückgeben.

Was ich für Wiederholungsversuche getan habe, ist eine Halte Exchange und Warteschlange zu erstellen. Wenn Sie eine Nachricht wiederholen möchten, geben Sie eine positive Bestätigung an die Warteschlange zurück, fügen Sie der Nachricht einen RetryAttepmts-Header hinzu und veröffentlichen Sie sie dann mit einem Zeitlimitwert in der HoldQueue Exchange. Legen Sie den Dead Letter Exchange der Warteschlangenwarteschlange an einen Exchange fest, der die Nachricht an die ursprüngliche Warteschlange sendet. Dann den Header prüfen und nack, wenn die Wiederholungsversuche zu groß sind

hier ist eine gute Website detailliert den Prozess http://yuserinterface.com/dev/2013/01/08/how-to-schedule-delay-messages-with-rabbitmq-using-a-dead-letter-exchange/

+0

Ja, ich sehe auch den gleichen Artikel. danke – techspider

+0

Wenn ich in WorkExchange viele Warteschlangen in dem Beispiel habe, wie stelle ich sicher, dass es nur zu WorkQueue1, aber nicht zu WorkQueue2 geht? Der Parameter verwendet x-dead-letter-exchange, aber keine Warteschlangen- oder Routing-Schlüssel. – techspider

+1

In diesem Fall benötigen Sie eine zusätzliche Exchange – Franklin

3

Ab Version 3.5.2 fügt RabbitMQ automatisch einen Header dead-letterred Nachrichten mit Informationen wie zum Beispiel:

  • der Warteschlange (n), die
  • der Grund der Meldung sah (n) es war tot-letterred
  • die Anzahl der Male war es tot letterred
  • Zeitstempel

Blick auf die "Dead-Lettered Messages" section near the end of the DLX documentation für weitere Details.

Wenn Sie eine ältere Version von RabbitMQ verwenden, sollte die @ Franklin-Lösung funktionieren.

+0

Danke, ich habe diesen Artikel gelesen; Gibt es auf ihrer Website ein .Net-Beispiel, das ich mir ansehen kann? Ich bin etwas verwirrt mit der Theorie :) – techspider

+0

Hmm, nein, mir sind keine Implementierungsbeispiele auf der Website bekannt. Wenn Sie sich die .NET-Client-Dokumentation ansehen, werden Sie vermutlich zuerst die [Eigenschaften einer Nachricht] erhalten (http://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.6.1/rabbitmq-dotnet-client-3.6.1-client-htmldoc/html/type-RabbitMQ.Client.IBasicProperties.html), dann greifen Sie auf die 'Headers'-Eigenschaft zu. 'Headers' ist ein Wörterbuch und der Schlüssel, an dem Sie interessiert sind, muss 'x-death' heißen. –

Verwandte Themen