Meldingsmellomvare er en mellomvareteknologi bestående av en meldingsoverføringsmekanisme eller meldingskømodus, som bruker en effektiv og pålitelig meldingsmekanisme for plattformuavhengig datautveksling, og integrerer distribuerte systemer basert på datakommunikasjon. For øyeblikket finnes det mange MQ-produkter i bransjen, som RabbitMQ, ActiveMQ, ZeroMQ osv., som er utmerket meldingsmellomvare, men hvilken bør vi velge i prosjektet? Denne artikkelen evaluerer og sammenligner følgende meldingskøprodukter: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Rendis og memcacheQ
Didigresjon: Her kan vi først tenke på et lite spørsmål: «Hvorfor trenger vi meldingskøtjenester i webapplikasjoner?» ”
For eksempel ankommer et stort antall insert-, oppdaterings- og andre forespørsler til MySQL samtidig, noe som direkte fører til utallige radlåser og tabelllåser, og til og med for mange forespørsler til slutt, noe som utløser for mange tilkoblingsfeil. Ved å bruke meldingskøer kan vi behandle forespørsler asynkront, noe som avlaster belastningen på systemet.
RabbitMQ
Det er en åpen kildekode-meldingskø skrevet i Erlang, som støtter mange protokoller: AMQP, XMPP, SMTP, STOMP, noe som gjør den svært tungvekts og mer egnet for utvikling på bedriftsnivå. Det er en ledende implementering av AMQP-protokollen, som implementerer en broker-arkitektur, noe som betyr at meldinger kan legges i kø på en sentral node før de sendes til klienten. Det finnes god støtte for ruting, lastbalansering eller datapersistens. Denne funksjonen gjør RabbitMQ enkelt å bruke og distribuere, egnet for mange scenarier som ruting, lastbalansering eller meldingspersistens, og kan gjøres med bare noen få linjer kode med meldingskøer. Dette gjør det imidlertid mindre skalerbart og tregere fordi den sentrale noden øker latenstiden og blir større etter innkapsling av meldingen. For å konfigurere RabbitMQ må du installere Erlang-miljøet på målmaskinen.
Klikk for å se dette bildet i et nytt vindu
? MQ(ZeroMQ)
Det er kjent som det raskeste systemet for meldingskøer, spesielt for scenarier med høy gjennomstrømning. Det er et svært lett meldingssystem utviklet spesielt for høy-gjennomstrømnings/lav-latens-scenarier, og kan ofte finnes i applikasjoner i finansverdenen. Sammenlignet med RabbitMQ støtter ZeroMQ mange avanserte meldingsscenarier, men du må implementere individuelle blokker i ZeroMQ-rammeverket (som sockets eller enheter, osv.).
? MQ (ZeroMQ) kan implementere avanserte/komplekse køer som RabbitMQ ikke er god på, men utviklere må kombinere flere tekniske rammeverk alene, og den tekniske kompleksiteten utgjør en utfordring for vellykket anvendelse av denne MQ-en. ZeroMQ har en unik ikke-mellomvare-modell hvor du ikke trenger å installere og kjøre en meldingsserver eller mellomvare fordi applikasjonen din vil spille denne tjenesterollen. Alt du trenger å gjøre er å referere til ZeroMQ-biblioteket, som kan installeres med NuGet, og du kan gjerne sende meldinger mellom applikasjoner. ZeroMQ tilbyr imidlertid kun ikke-persistente køer, noe som betyr at hvis maskinen går ned, vil dataene gå tapt. Blant dem bruker Twitters Storm ZeroMQ som overføring av datastrømmer. ZeroMQ er veldig fleksibelt, men du må lære deg den 80-siders manualen (hvis du skriver om et distribuert system, sørg for å lese den).
ZeroMQ har ingen mellomvarearkitektur og krever ingen serviceprosesser og kjøringer. Faktisk spiller applikasjonsendepunktet din denne tjenesterollen. Dette gjør det veldig enkelt å implementere, men bekymringen er at du ikke har noe sted å se hvis noe går galt med den. Så vidt vi vet, tilbyr ZeroMQ kun ikke-persistente køer. Du kan implementere dine egne revisjons- og datagjenopprettingsmuligheter der du trenger det.
Klikk for å se dette bildet i et nytt vindu
MSMQ
Dette er det eneste i Microsofts produkt som regnes som verdifullt. Hvis MSMQ kan bevise at den kan håndtere denne typen oppgave, vil de velge å bruke den. Poenget er at dette ikke er komplisert, bare mottak og sending; Den har noen harde begrensninger, som maksimal meldingsstørrelse på 4MB. Den kan imidlertid løse disse problemene ved å koble til programvare som MassTransit eller NServiceBus.
Klikk for å se dette bildet i et nytt vindu
Jafka/Kafka
Kafka (som distribuerer meldinger på tvers av ulike noder) er et distribuert MQ-system utviklet og åpen kildekode av LinkedIn i desember 2010, og er nå et inkubasjonsprosjekt for Apache, et høyytelses tverrspråklig distribuert Publish/Subscribe-meldingskøsystem, og Jafka inkuberes oppå Kafka, som er en oppgradert versjon av Kafka. Den har følgende egenskaper: rask persistens, som kan lagre meldinger under systemoverhead på O(1); Høy gjennomstrømning, som kan nå en gjennomstrømningshastighet på 10W/s på en vanlig server; Fullstendig distribuerte systemer, megler, produsent og forbruker støtter alle distribuert nativt og oppnår automatisk kompleks likevekt. Støtter parallell lasting av Hadoop-data, som er en levedyktig løsning for loggdata og offline analysesystemer som Hadoop, men med begrensningene ved sanntidsbehandling. Kafka forener online og offline meldingsbehandling gjennom Hadoops parallelle lastemekanisme, som også er viktig for systemet som studeres i dette emnet. Apache Kafka er et svært lett meldingssystem sammenlignet med ActiveMQ, og i tillegg til svært god ytelse er det også et distribuert system som fungerer godt.
Klikk for å se dette bildet i et nytt vindu
Apache ActiveMQ
ActiveMQ ligger et sted mellom de to (RabbitMQ og ZeroMQ), lik ZemoMQ, og kan distribueres både i proxy- og P2P-modus. På samme måte som RabbitMQ er det lett å implementere avanserte scenarier og krever lavt forbruk.
ActiveMQ er kjent som ryggraden i Java-verdenen. Den har en lang historie og er mye brukt. Det er også plattformuavhengig, og gir et naturlig integrasjonspunkt for produkter som ikke er på Microsofts plattform. Det er imidlertid kun mulig å bli vurdert hvis det har passert MSMQ. For å konfigurere ActiveMQ må du installere Java-miljøet på målmaskinen.
Klikk for å se dette bildet i et nytt vindu
Det er viktig å merke seg at ActiveMQs neste generasjons produkt er Apollo, som er basert på ActiveMQ-prototypen og er et raskere, mer pålitelig og enklere å vedlikeholde meldingsmeglerverktøy. Apache kaller Apollo den raskeste og mest robuste STOMP (Streaming Text Orientated Message Protocol)-serveren.
Egenskapene til Apollo er som følger:
Stomp 1.0- og Stomp 1.1-protokoller støttes
Temaer og køer
Kø-nettleser
Tema-persistente abonnementer
Speilkø
Pålitelig meldingsutveksling
Meldingsutløp og utveksling
Meldingsplukker
JAAS verifisert
ACL-basert autorisasjon
Støtt SSL/TLS og sertifikatvalidering
REST Management API
Klikk for å se dette bildet i et nytt vindu
Redis
Det er en Key-Value NoSQL-database, som aktivt utvikles og vedlikeholdes, selv om det er et Key-Value-databaselagringssystem, men den støtter MQ-funksjoner, slik at den kan brukes som en lettvekts køtjeneste. For onboarding og ut-kø-operasjoner for RabbitMQ og Redis, 1 million ganger hver, og kjøretiden registreres hver 100 000 ganger. Testdataene er delt inn i fire forskjellige størrelser: 128 byte, 512 byte, 1K og 10K. Eksperimenter viser at når man blir med i teamet, er ytelsen til Redis høyere enn til RabbitMQ når datasammenligningen er liten, og hvis datastørrelsen overstiger 10K, er Redis uutholdelig treg. Da Redis forlot teamet, viste han svært god ytelse uansett datastørrelse, mens RabbitMQs prestasjon var mye lavere enn Redis'.
MemcacheQ
Persistent meldingskø Memcacheq (MCQ for kort) er en lett meldingskø, MemcacheQ funksjoner:
1 Enkelt og lett å bruke
2 Rask behandling
3 Flere køer
4 God samtidighetsytelse
5 Kompatibel med Memcache-protokollen. Dette betyr at du bare må installere memcache-utvidelsen, ingen ekstra plugins kreves.
6 Det er også praktisk å bruke i zend-rammeverket.
Til syvende og sist er disse produktene:
1. Begge har sine egne klient-API-er eller støtter flere programmeringsspråk;
2. Det finnes mye dokumentasjon;
3. Positiv støtte ble gitt.
4. ActiveMQ, RabbitMQ, MSMQ, Redis må alle starte tjenesteprosesser, som kan overvåkes og konfigureres, mens de andre er problematiske
5. De gir alle relativt god pålitelighet (konsistens), skalerbarhet og lastbalansering, og selvfølgelig ytelse
Jeg skal ikke snakke tull her, vedlagt nedenfor er et sett med testresultater hentet fra Internett. Antall meldinger sendt og mottatt per sekund vises. Hele prosessen genererte totalt 1 million 1K-meldinger. Testen ble utført på en frittstående Windows Vista-maskin.
Som du ser, er ikke ZeroMQ et nivå som noe annet. Ytelsen er overraskende høy. Til tross for dette gir ikke dette produktet meldingspersistens, kan ikke enkelt lagre og overvåke mellomliggende prosesser, og krever selvrevisjon og datagjenoppretting, så det er ikke tilfredsstillende når det gjelder brukervennlighet og HA. Konklusjonen er klar: hvis du vil at en app skal sende meldinger så raskt som mulig, velger du ZeroMQ. Det er mer verdifullt når du ikke bryr deg så mye om å miste visse meldinger ved en tilfeldighet.
Bloggeren i denne artikkelen håper (og håper ikke så mye) å bruke Rabbit, Rabbitmq har innebygd ha, hvis du danner en klynge, trenger du ikke bekymre deg for problemer som lastbalansering, og du kan sette opp et køspeil. Men denne typen ting er at det burde vært mer testing, og du ender opp med en favoritt, og alt jeg har hørt og lest om Rabbit får meg til å føle at det burde være det beste valget.
|
Publisert på 15.12.2016 10:52:40
|
|
|
|
