Översättning
Meddelanden är en grundläggande del av alla distribuerade system. Det gör det möjligt för en producent att skicka ett meddelande till valfritt antal konsumenter, och det är inte nödvändigt att känna till någon information om konsumenten. Detta är till stor hjälp för verkligt asynkron och avkopplande kommunikation.
När du använder RabbitMQ visar diagrammet ovan en mycket grundläggande men typisk struktur. En producent skickar ett meddelande till switchen. Enligt routningslogiken placerar växeln meddelandet i kön som är bunden till växeln. Mer specifikt, om det är en broadcast-typ switch, kommer kopian av detta meddelande att skickas till varje kö upprepade gånger. En konsument kan då ta emot och bearbeta meddelandet.
En viktig förutsättning för att ovanstående struktur ska fungera framgångsrikt för producenter och konsumenter är att alla RabbitMQ-komponenter (dvs. köer, switchar och bindningar) måste skapas i förväg. En konsument kan inte skicka ett meddelande till en switch Om switchen inte existerar kan en konsument inte bearbeta meddelanden från en kö som inte finns.
Därför är det inte svårt att förstå att innan producent/konsument skickar/tar emot meddelandet, låt ett producent/konsumentvärde skapa en kö-, switch- och bindningsrelation. Låt oss titta på för- och nackdelarna med båda sätten.
1. Särskilj ansvarsområden
Bildöversättning (1. Producenten skapar en switch 2. Konsumenten skapar en kö och binder köen till switchen)
För att producenter och konsumenter ska kunna koppla loss helt, är det idealiskt att producenter bara känner till information om switchen (inte kön), och konsumenterna känner bara till kön (inte switchen). Bindningsrelationen anger sambandet mellan switchen och kön
Ett möjligt sätt är att låta producenten hantera skapandet av switchen, och konsumenten skapar kön och binder kön till switchen. Fördelen med denna avkopplingsmetod är att om konsumenten behöver en kö är det helt enkelt nödvändigt att skapa en kö och binda den efter efterfrågan, och producenten behöver inte känna till någon information om kön. Men detta är inte en tillräcklig avkoppling: eftersom konsumenten måste känna till switchen för att binda den.
2. Producenter skapar allt
När producenten körs kan den konfigureras för att skapa alla nödvändiga komponenter (switchar, köer och bindningar). Fördelen med detta tillvägagångssätt är att inga meddelanden går förlorade (eftersom kön redan är skapad och bunden till switchen, och ingen konsument behöver starta den först).
Detta innebär dock att producenten måste känna till alla köer som behöver kopplas till switchen. Detta är ett mycket kopplat sätt. Anledningen är att varje gång en ny kö behöver läggas till måste producenten omkonfigurera och distribuera för att skapa och binda köer
3. Konsumenter skapar allt
Motsatsen är att låta konsumenten skapa de switchar, köer och bindningar den behöver när den körs. Precis som i det tidigare tillvägagångssättet ger denna metod koppling eftersom konsumenten måste känna till informationen om den switch de är bundna till kön. Alla ändringar i switchen (såsom namnbyte) innebär att alla konsumenter måste konfigureras om och distribueras. När det finns långa köer och konsumenter kan denna komplexitet bli för stor.
4. Ingen av dem skapar något
Ett helt annat tillvägagångssätt är att varken producenten eller konsumenten ska skapa några nödvändiga komponenter. Istället skapas det med användargränssnittet i admin-pluginet eller admin-CLI:n i förväg. Denna metod bygger på följande fördelar:
- Producenter och konsumenter kan vara helt frånkopplade. Producenter känner bara till utbytet, och konsumenterna känner bara till kön.
- Detta kan enkelt skriptas och automatiseras som en del av distributionskedjan
- Alla förändringar, såsom nya köer, kan läggas till utan att röra befintliga, distribuerade utgivare och konsumenter
sammanfattning
I distribuerade system är asynkrona meddelanden ett användbart sätt att koppla loss, men för att hålla dem frikopplade är det nödvändigt att upprätthålla en effektiv strategi för att upprätthålla den underliggande meddelandestrukturen (i RabbitMQ är detta köer, switchar och bindningar).
Även om utgivare och konsumenttjänster kan vara ansvariga för att själva skapa det de behöver, kan de vara kostsamma när det gäller initial meddelandeförlust, koppling och operativt underhåll (vad gäller konfiguration och distribution).
Förmodligen det bästa sättet att hantera meddelandesystemkonfiguration där den hör hemma: skriv skript utanför applikationen. Detta säkerställer att tjänster förblir frikopplade och att kösystemet kan ändras dynamiskt vid behov utan att påverka ett stort antal befintliga tjänster.
Original:Inloggningen med hyperlänken är synlig.
Originalengelska:Inloggningen med hyperlänken är synlig.
|
Publicerad på 2023-05-03 22:31:59
|
|
|
|
