Beskedmiddleware er en middleware-teknologi bestående af en meddelelsesoverførselsmekanisme eller beskedkø-tilstand, som bruger en effektiv og pålidelig beskedmekanisme til platformuafhængig dataudveksling og integrerer distribuerede systemer baseret på datakommunikation. I øjeblikket findes der mange MQ-produkter i branchen, såsom RabbitMQ, ActiveMQ, ZeroMQ osv., som er fremragende beskedmiddleware, men hvilken skal vi vælge i projektet? Denne artikel evaluerer og sammenligner følgende beskedkøprodukter: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis og memcacheQ
Digression: Her kan vi først tænke over et lille spørgsmål: "Hvorfor har vi brug for beskedkøtjenester i webapplikationer?" ”
For eksempel ankommer et stort antal insert-, opdaterings- og andre forespørgsler til MySQL samtidig, hvilket direkte fører til utallige række- og tabellåse, og endda for mange forespørgsler til sidst, hvilket udløser for mange forbindelsesfejl. Ved at bruge beskedkøer kan vi behandle forespørgsler asynkront og dermed lette belastningen på systemet.
RabbitMQ
Det er en open source beskedkø skrevet i Erlang, som understøtter mange protokoller: AMQP, XMPP, SMTP, STOMP, hvilket gør den meget tung og mere velegnet til udvikling på virksomhedsniveau. Det er en førende implementering af AMQP-protokollen, som implementerer en broker-arkitektur, hvilket betyder, at beskeder kan placeres i kø på en central node, før de sendes til klienten. Der er god understøttelse af routing, load balancing eller datapersistens. Denne funktion gør RabbitMQ nemt at bruge og implementere, velegnet til mange scenarier såsom routing, load balancing eller beskedpersistens, og kan udføres med blot få linjer kode via beskedkøer. Dette gør dog den mindre skalerbar og langsommere, fordi den centrale node øger latenstiden og er større efter beskedindkapsling. For at konfigurere RabbitMQ skal du installere Erlang-miljøet på målmaskinen.
Klik for at se dette billede i et nyt vindue
? MQ(ZeroMQ)
Det er kendt som det hurtigste beskedkøsystem, især i scenarier med høj gennemstrømning. Det er et meget letvægts beskedsystem udviklet specifikt til højkapacitet/lav latenstid og kan ofte findes i applikationer i finansverdenen. Sammenlignet med RabbitMQ understøtter ZeroMQ mange avancerede beskedscenarier, men du skal implementere individuelle blokke i ZeroMQ-rammen (såsom sockets eller enheder osv.).
? MQ (ZeroMQ) kan implementere avancerede/komplekse køer, som RabbitMQ ikke er god til, men udviklere skal selv kombinere flere tekniske rammer, og den tekniske kompleksitet er en udfordring for en succesfuld anvendelse af denne MQ. ZeroMQ har en unik ikke-middleware-model, hvor du ikke behøver at installere og køre en beskedserver eller middleware, fordi din applikation vil spille denne servicerolle. Alt du skal gøre er blot at henvise til ZeroMQ-biblioteket, som kan installeres med NuGet, og så kan du sagtens sende beskeder mellem applikationer. ZeroMQ tilbyder dog kun ikke-persistente køer, hvilket betyder, at hvis maskinen går ned, vil dataene gå tabt. Blandt dem bruger Twitters Storm ZeroMQ som transmission af datastrømme. ZeroMQ er meget fleksibel, men du skal lære dens 80-siders manual (hvis du skriver om et distribueret system, så sørg for at læse den).
ZeroMQ har ingen middleware-arkitektur og kræver ingen serviceprocesser og kørsler. Faktisk spiller dit applikationsendepunkt denne servicerolle. Det gør det meget nemt at implementere, men bekymringen er, at du ikke har noget sted at kigge, hvis noget går galt med det. Så vidt vi ved, tilbyder ZeroMQ kun ikke-persistente køer. Du kan implementere dine egne revisions- og datagendannelsesfunktioner, hvor du har brug for det.
Klik for at se dette billede i et nyt vindue
MSMQ
Dette er det eneste i Microsofts produkt, der anses for værdifuldt. Hvis MSMQ kan bevise, at den kan håndtere denne slags opgaver, vil de vælge at bruge den. Pointen er, at denne ting ikke er kompliceret, intet andet end modtagelse og afsendelse; Den har nogle hårde begrænsninger, såsom den maksimale beskedstørrelse på 4MB. Dog kan den løse disse problemer ved at forbinde til noget software som MassTransit eller NServiceBus.
Klik for at se dette billede i et nyt vindue
Jafka/Kafka
Kafka (som distribuerer beskeder på tværs af forskellige noder) er et distribueret MQ-system udviklet og open source af LinkedIn i december 2010, og er nu et inkubationsprojekt for Apache, et højtydende, tværsproget distribueret Publish/Subscribe-beskedkøsystem, og Jafka inkuberes oven på Kafka, som er en opgraderet version af Kafka. Den har følgende egenskaber: hurtig persistens, som kan bevare beskeder under systemoverhead af O(1); Høj gennemstrømning, som kan nå en gennemstrømningshastighed på 10W/s på en almindelig server; Fuldstændigt distribuerede systemer, mægler, producent og forbruger understøtter alle distribueret system nativt og opnår automatisk kompleks ligevægt. Understøtter parallel indlæsning af Hadoop-data, hvilket er en levedygtig løsning til logdata og offline analysesystemer som Hadoop, men med begrænsninger ved realtidsbehandling. Kafka forener online og offline meddelelsesbehandling gennem Hadoops parallelle indlæsningsmekanisme, som også er vigtig for det system, der studeres i dette emne. Apache Kafka er et meget let beskedsystem sammenlignet med ActiveMQ, og ud over meget god ydeevne er det også et distribueret system, der fungerer godt.
Klik for at se dette billede i et nyt vindue
Apache ActiveMQ
ActiveMQ ligger et sted mellem de to (RabbitMQ & ZeroMQ), ligesom ZemoMQ, og kan implementeres både i proxy- og P2P-tilstande. Ligesom RabbitMQ er det nemt at implementere avancerede scenarier og kræver lavt forbrug.
ActiveMQ er kendt som rygraden i Java-verdenen. Den har en lang historie og bruges bredt. Det er også platformtværligt og giver et naturligt integrationsadgangspunkt for produkter, der ikke findes på Microsofts platform. Det er dog kun muligt at blive betragtet, hvis det har kørt forbi MSMQ. For at konfigurere ActiveMQ skal du installere Java-miljøet på målmaskinen.
Klik for at se dette billede i et nyt vindue
Det er vigtigt at bemærke, at ActiveMQ's næste generations produkt er Apollo, som er baseret på ActiveMQ-prototypen og er et hurtigere, mere pålideligt og lettere vedligeholdelsesværktøj til beskedformidler. Apache kalder Apollo den hurtigste og mest robuste STOMP (Streaming Text Orientated Message Protocol) server.
Apollos funktioner er som følger:
Stomp 1.0 og Stomp 1.1 protokoller understøttes
Emner og køer
Købrowser
Tema-persistent-abonnementer
Spejlkø
Pålidelig beskedudveksling
Beskedudløb og udveksling
Beskedvælger
JAAS verificeret
ACL-baseret autorisation
Understøttelse af SSL/TLS og certifikatvalidering
REST Management API
Klik for at se dette billede i et nyt vindue
Redis
Det er en Key-Value NoSQL-database, som aktivt udvikles og vedligeholdes, selvom det er et Key-Value databaselagringssystem, understøtter den MQ-funktioner, så den kan bruges som en letvægts køservice. For onboarding- og out-queue-operationerne af RabbitMQ og Redis hver 1 million gange, og eksekveringstiden registreres hver 100.000 gange. Testdataene er opdelt i fire forskellige størrelser: 128Bytes, 512Bytes, 1K og 10K. Eksperimenter viser, at når man slutter sig til teamet, er Redis' ydeevne højere end RabbitMQ, når datasammenligningen er lille, og hvis datastørrelsen overstiger 10K, er Redis uudholdeligt langsom. Da Redis forlod teamet, viste han meget god præstation uanset datastørrelsen, mens RabbitMQ's præstation var meget lavere end Redis'.
MemcacheQ
Persistent meddelelseskø Memcacheq (forkortet MCQ) er en letvægts meddelelseskø, MemcacheQ funktioner:
1 Simpelt og nemt at bruge
2 Hurtig behandling
3 Flere køer
4 God samtidighedspræstation
5 Kompatibel med Memcache-protokollen. Det betyder, at man bare skal installere memcache-udvidelsen, der kræves ingen yderligere plugins.
6 Det er også praktisk at bruge i zend-frameworket.
I sidste ende er disse produkter:
1. Begge har deres egne klient-API'er eller understøtter flere programmeringssprog;
2. Der er meget dokumentation;
3. Positiv støtte blev givet.
4. ActiveMQ, RabbitMQ, MSMQ, Redis skal alle starte serviceprocesser, som kan overvåges og konfigureres, og de andre er problematiske
5. De giver alle relativt god pålidelighed (konsistens), skalerbarhed og belastningsbalancering samt selvfølgelig ydeevne
Jeg vil ikke snakke vrøvl her, vedhæftet nedenfor er et sæt testresultater opsnappet fra internettet. Antallet af sendte og modtagne beskeder pr. sekund vises. Hele processen genererede i alt 1 million 1.000 beskeder. Testen blev udført på en Windows Vista stand-alone maskine.
Som du kan se, er ZeroMQ ikke et niveau som noget andet. Dens ydeevne er overraskende høj. På trods af dette giver dette produkt ikke beskedpersistens, kan ikke nemt lagre og overvåge mellemliggende processer og kræver selvrevision og datagendannelse, så det er ikke tilfredsstillende med hensyn til brugervenlighed og HA. Konklusionen er klar: hvis du vil have en app til at sende beskeder så hurtigt som muligt, vælger du ZeroMQ. Det er mere værdifuldt, når du ikke går så meget op i at miste visse beskeder ved et tilfælde.
Bloggeren i denne artikel håber (og håber ikke meget) at bruge Rabbit, Rabbitmq har indbygget ha, hvis du danner en klynge, behøver du ikke bekymre dig om problemer som load balancing, og du kan sætte et kø-spejl op. Men den slags ting er, at der burde være mere test, og man ender med en favorit, og alt det, jeg har hørt og læst om Rabbit, får mig til at føle, at det burde være det bedste valg.
|
Opslået på 15/12/2016 10.52.40
|
|
|
|
