Meddelandemellanvara är en mellanvaruteknologi bestående av en meddelandeöverföringsmekanism eller meddelandekösläge, som använder en effektiv och pålitlig meddelandemekanism för plattformsoberoende datautbyte och integrerar distribuerade system baserade på datakommunikation. För närvarande finns det många MQ-produkter i branschen, såsom RabbitMQ, ActiveMQ, ZeroMQ med flera, som är utmärkt meddelande-middleware, men vilken bör vi välja i projektet? Denna artikel utvärderar och jämför följande meddelandeköprodukter: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis och memcacheQ
Avvikelse: Här kan vi först fundera på en liten fråga: "Varför behöver vi meddelandekötjänster i webbapplikationer?" ”
Till exempel anländer ett stort antal insert-, uppdaterings- och andra förfrågningar till MySQL samtidigt, vilket direkt leder till otaliga radlås och tabelllås, och till och med för många förfrågningar i slutändan, vilket utlöser för många anslutningsfel. Genom att använda meddelandeköer kan vi behandla förfrågningar asynkront, vilket avlastar belastningen på systemet.
RabbitMQ
Det är en öppen källkods-meddelandekö skriven på Erlang, som stöder många protokoll: AMQP, XMPP, SMTP, STOMP, vilket gör den mycket tungvikt och mer lämplig för företagsnivåutveckling. Det är en ledande implementation av AMQP-protokollet, som implementerar en mäklararkitektur, vilket innebär att meddelanden kan köas på en central nod innan de skickas till klienten. Det finns bra stöd för routing, lastbalansering eller datapersistens. Denna funktion gör RabbitMQ lätt att använda och distribuera, lämpligt för många scenarier såsom routning, lastbalansering eller meddelandepersistens, och kan göras med bara några få rader kod med meddelandeköer. Detta gör dock att den är mindre skalbar och långsammare eftersom centralnoden ökar latensen och blir större efter meddelandeinkapsling. För att konfigurera RabbitMQ måste du installera Erlang-miljön på måldatorn.
Klicka för att se denna bild i ett nytt fönster
? MQ(ZeroMQ)
Det är känt som det snabbaste systemet för meddelandeköer, särskilt för scenarier med hög genomströmningsefterfrågan. Det är ett mycket lättviktigt meddelandesystem utvecklat specifikt för scenarier med hög genomströmning och låg latens och kan ofta hittas i applikationer inom finansvärlden. Jämfört med RabbitMQ stöder ZeroMQ många avancerade meddelandescenarier, men du måste implementera individuella block i ZeroMQ-ramverket (såsom sockets eller enheter, etc.).
? MQ (ZeroMQ) kan implementera avancerade/komplexa köer som RabbitMQ inte är bra på, men utvecklare behöver kombinera flera tekniska ramverk på egen hand, och den tekniska komplexiteten är en utmaning för en framgångsrik tillämpning av denna MQ. ZeroMQ har en unik icke-middleware-modell där du inte behöver installera och köra en meddelandeserver eller middleware eftersom din applikation kommer att spela denna tjänsteroll. Allt du behöver göra är att bara referera till ZeroMQ-biblioteket, som kan installeras med NuGet, och du kan enkelt skicka meddelanden mellan applikationer. ZeroMQ tillhandahåller dock endast icke-persistenta köer, vilket innebär att om maskinen går ner, förloras datan. Bland dem använder Twitters Storm ZeroMQ som överföring av dataströmmar. ZeroMQ är mycket flexibelt, men du måste lära dig dess 80-sidiga manual (om du skriver om ett distribuerat system, se till att läsa den).
ZeroMQ har ingen middleware-arkitektur och kräver inga serviceprocesser och körningar. Faktum är att din applikationsändpunkt spelar denna tjänsteroll. Detta gör det väldigt enkelt att implementera, men oron är att du inte har någonstans att titta om något går fel med det. Så vitt vi vet erbjuder ZeroMQ endast icke-persistenta köer. Du kan implementera egna revisions- och dataåterställningsfunktioner där du behöver dem.
Klicka för att se denna bild i ett nytt fönster
MSMQ
Detta är det enda i Microsofts produkt som anses vara värdefullt. Om MSMQ kan bevisa att den klarar av denna typ av uppgift, kommer de att välja att använda den. Poängen är att detta inte är komplicerat, inget annat än att ta emot och skicka; Det har vissa hårda begränsningar, såsom den maximala meddelandestorleken på 4 MB. Men det kan lösa dessa problem genom att ansluta till viss programvara som MassTransit eller NServiceBus.
Klicka för att se denna bild i ett nytt fönster
Jafka/Kafka
Kafka (som distribuerar meddelanden mellan olika noder) är ett distribuerat MQ-system utvecklat och öppet källkodsgjort av LinkedIn i december 2010, och är nu ett inkubationsprojekt för Apache, ett högpresterande tvärspråkigt distribuerat Publish/Subscribe-meddelandekösystem, och Jafka inkuberas ovanpå Kafka, som är en uppgraderad version av Kafka. Den har följande egenskaper: snabb persistens, som kan behålla meddelanden under systemöverhead O(1); Hög genomströmning, som kan nå en genomströmningshastighet på 10W/s på en vanlig server; Helt distribuerade system, mäklare, producent och konsument stöder alla distribuerat och uppnår automatiskt komplex jämvikt. Stöder parallell inläsning av Hadoop-data, vilket är en gångbar lösning för loggdata och offline-analyssystem som Hadoop, men med begränsningarna av realtidsbearbetning. Kafka förenar online- och offline-meddelandebehandling genom Hadoops parallella laddningsmekanism, vilket också är viktigt för det system som studeras i detta ämne. Apache Kafka är ett mycket lättviktigt meddelandesystem jämfört med ActiveMQ, och förutom mycket god prestanda är det också ett distribuerat system som fungerar bra.
Klicka för att se denna bild i ett nytt fönster
Apache ActiveMQ
ActiveMQ ligger någonstans mellan de två (RabbitMQ och ZeroMQ), liknande ZemoMQ, och kan distribueras både i proxy- och P2P-lägen. Liknande RabbitMQ är det enkelt att implementera avancerade scenarier och kräver låg konsumtion.
ActiveMQ är känt som ryggraden i Java-världen. Den har en lång historia och används flitigt. Det är också plattformsoberoende och ger en naturlig integrationsåtkomstpunkt för produkter som inte finns på Microsofts plattform. Det är dock bara möjligt att övervägas om den har passerat MSMQ. För att konfigurera ActiveMQ måste du installera Java-miljön på måldatorn.
Klicka för att se denna bild i ett nytt fönster
Det är viktigt att notera att ActiveMQ:s nästa generations produkt är Apollo, som bygger på ActiveMQ-prototypen och är ett snabbare, mer pålitligt och lättare underhållet meddelandemäklareverktyg. Apache kallar Apollo den snabbaste och mest robusta STOMP-servern (Streaming Text Orientated Message Protocol).
Apollos egenskaper är följande:
Stomp 1.0- och Stomp 1.1-protokoll stöds
Ämnen och köer
Kö-webbläsare
Temabeständiga prenumerationer
Spegelkö
Pålitlig meddelandehantering
Meddelandets utgångsdatum och utbyte
Meddelandeväljare
JAAS verifierat
ACL-baserad auktorisation
Stöd SSL/TLS och certifikatvalidering
REST Management API
Klicka för att se denna bild i ett nytt fönster
Redis
Det är en Key-Value NoSQL-databas, som aktivt utvecklas och underhålls, även om det är ett Key-Value-databaslagringssystem, men den stöder MQ-funktioner, så den kan användas som en lättviktskötjänst. För onboarding och out-queue-operationer för RabbitMQ och Redis, 1 miljon gånger vardera, och exekveringstiden registreras var 100 000:e gång. Testdatan är indelad i fyra olika storlekar: 128 byte, 512 byte, 1K och 10 K. Experiment visar att när man ansluter sig till teamet är Redis prestanda högre än RabbitMQ när datajämförelsen är liten, och om datastorleken överstiger 10K är Redis outhärdligt långsam. När Redis lämnade teamet visade han mycket bra prestation oavsett datastorlek, medan RabbitMQ:s prestation var mycket lägre än Redis.
MemcacheQ
Persistent meddelandekö Memcacheq (MCQ för kort) är en lättviktig meddelandekö, MemcacheQ funktioner:
1 Enkelt och lätt att använda
2 Snabb bearbetning
3 Flera köer
4 God samtidighetsprestation
5 Kompatibel med Memcache-protokollet. Det betyder att man bara installerar memcache-tillägget, inga ytterligare plugins krävs.
6 Det är också bekvämt att använda i zend-ramverket.
I slutändan är dessa produkter:
1. Båda har sina egna klient-API:er eller stöder flera programmeringsspråk;
2. Det finns mycket dokumentation;
3. Positivt stöd gavs.
4. ActiveMQ, RabbitMQ, MSMQ, Redis måste alla starta serviceprocesser, som kan övervakas och konfigureras, och de andra är problematiska
5. De ger alla relativt god tillförlitlighet (konsekvens), skalbarhet och lastbalansering, och naturligtvis prestanda
Jag ska inte prata nonsens här, bifogat nedan finns en uppsättning testresultat som avlyssnats från internet. Antalet meddelanden som skickas och tas emot per sekund visas. Hela processen genererade totalt 1 miljon 1K-meddelanden. Testet utfördes på en fristående Windows Vista-maskin.
Som du kan se är ZeroMQ inte en nivå som något annat. Dess prestanda är förvånansvärt hög. Trots detta ger denna produkt inte meddelandepersistens, kan inte enkelt lagra och övervaka mellanliggande processer och kräver självgranskning och dataåterställning, vilket gör den inte tillfredsställande vad gäller användarvänlighet och HA. Slutsatsen är tydlig: om du vill att en app ska skicka meddelanden så snabbt som möjligt, väljer du ZeroMQ. Det är mer värdefullt när du inte bryr dig så mycket om att förlora vissa meddelanden av en slump.
Bloggaren i den här artikeln hoppas (och hoppas inte särskilt mycket) använda Rabbit, Rabbitmq har inbyggd ha, om du bildar ett kluster behöver du inte oroa dig för problem som lastbalansering, och du kan sätta upp en köspegel. Men den här typen av grejer är att det borde göras mer testning, och man får en favorit, och allt jag hört och läst om Rabbit får mig att känna att det borde vara det bästa valet.
|
Publicerad på 2016-12-15 10:52:40
|
|
|
|
