|
|
Publicerad på 2018-04-09 10:23:21
|
|
|
|
Som standard sparas inte rabbitMQ-kömeddelanden på hårddisken, vilket innebär att när rabbitMQ-tjänsten startas om går meddelandena förlorade.
Beständighet av köer
Till exempel identifieras köns beständighetdurableis satt till true, vilket betyder att det är en persistent kö, och efter att tjänsten startats om kommer den också att existera, eftersom tjänsten lagrar den bevarade kön på hårddisken, och när tjänsten startas om kommer den att återupprätta den tidigare bevarade kön. Kön kan vara kvar, men om meddelandena inuti är beständiga beror på meddelandets persistensinställningar. Med andra ord, om inget meddelande skickas i kön före omstarten, beror det på meddelandeinställningarna som inträffade när meddelandet skickades om det ursprungliga meddelandet fortfarande finns kvar i kön efter omstarten.
Om du vill behålla meddelanden persistent efter en omstart måste du ställa in identiteten där meddelandet ska vara bevarat.
Ställ in köpersistens:
Den fjärde parametern i metoden, autoDelete, anges vanligtvis som falsk. Dokumentationen beskriver denna parameter om den är sann, vilket innebär att om kön inte längre används (inte prenumererar), kommer servern att radera den. Under mina tester, så länge alla mottagare av anslutningsbyteskön är frånkopplade, raderas kön, även om det fortfarande finns obehandlade meddelanden i den. RabbitMQ-omstarter tar också bort dem. Om falskt anges kommer tjänsten inte att radera kön och meddelandena i kön kommer att finnas kvar om alla klienter som är anslutna till den är bortkopplade. Avsändaren kan också lägga in meddelanden i ändringskön när det inte finns någon klientanslutning, och när klienten kommer upp får den dessa meddelanden. Men om RabbitMQ-tjänsten startas om kommer kön att vara borta och meddelandena i den försvinner naturligt.
Den tredje parametern är exklusiv, och dokumentationen anger att om den är sann, så bryts anslutningen till kön, och kön raderas, inklusive meddelandena inuti.
Den andra parametern, durable, beskrivs i dokumentationen som att om den är sann, representerar den en persistent kö, som också kommer att finnas kvar efter att tjänsten startats om. Eftersom tjänsten lagrar den persistenta kön på hårddisken, och när tjänsten startas om, bekräftar den denna kö. Självklart måste det vara när både autoDelete och exklusiv är falska. Kön kan vara kvar, men om meddelandena inuti är beständiga beror på meddelandets persistensinställningar. Med andra ord, om det fortfarande finns meddelanden som skickas i kön före omstarten, beror det på avsändarens inställningar för meddelandet när meddelandet skickas om det ursprungliga meddelandet fortfarande finns kvar i kön efter omstarten.
Efter att vi ändrat koden försöker vi köra den, och felet blir följande:
Ohanterat undantag: RabbitMQ.Client.Exceptions.OperationInterruptedException: AMQP-operationen avbröts: AMQP stäng-reason, initierad av Peer, code=406, text="PRECONDITION_FAILED - Ekvivalent arg 'durable' för kö 'hello' i vhost 'myserver': received 'true' men current is 'false'", classId=50, methodId=10, cause=
För vi har definierat en icke-persisterad kö som heter hello. RabbitMQ tillåter inte omdefiniering av befintliga köer med olika parameterinställningar.
Det finns två lösningar:
1: Deklarera en kö på nytt med ett annat namn, såsom my_queue
2: Radera den definierade "hello"-kön med adressen http://localhost:15672 och logga in med användarnamn och lösenord. Standardlösenordet och användarnamnet för RabbitMQ är gäst. Klicka på kolumnen "kö" för att se kölistan, klicka på "hello"-kön för att utöka ködetaljerna. Dra sidan till slutet, det finns ett objekt "Ta bort", klicka på det, klicka på knappen "Ta bort kö" och du kan ta bort kön. När koden körs skapas en hello-kö som stödjer persistens.
Meddelandens beständighet
Om du vill behålla meddelandet bestående efter en omstart måste du ställa in meddelandet att bestå. Inställningen är när avsändaren skickar den, vilket är relativt enkelt, och koden är följande:
DeliveryMode är standard 1, icke-persistent, och inställning till 2 betyder att meddelandet är persistent
Efter att vi ändrat koden försöker vi bara öppna producerprogrammet för att skicka meddelanden, och sedan starta om rabbitMQ-tjänsten, öppna konsumenten igen och upptäcka att meddelandet inte är förlorat.
(Slut)
Bifogat är C#-källkoden:
Turister, om ni vill se det dolda innehållet i detta inlägg, snälla Svar
|
Föregående:Undantagsmeddelande: "StrongTypingException: IsPrima...Nästa:Introduktion till C#-delegater (delegat, Handling, Func, predikat)
|
Publicerad på 2018-04-09 13:17:51
|
Hyresvärd