Message middleware is een middleware-technologie die bestaat uit een berichtoverdrachtsmechanisme of message queue-modus, die een efficiënt en betrouwbaar berichtenmechanisme gebruikt voor platformonafhankelijke gegevensuitwisseling en gedistribueerde systemen integreert op basis van datacommunicatie. Op dit moment zijn er veel MQ-producten in de industrie, zoals RabbitMQ, ActiveMQ, ZeroMQ, enzovoort, die uitstekende berichtmiddleware zijn, maar welke moeten we kiezen in het project? Dit artikel evalueert en vergelijkt de volgende berichtwachtrijproducten: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Rendis en memcacheQ
Afwijking: Hier kunnen we eerst nadenken over een kleine vraag: "Waarom hebben we message queue-diensten nodig in webapplicaties?" ”
Zo komen er bijvoorbeeld een groot aantal insert-, update- en andere verzoeken tegelijk binnen bij MySQL, wat direct leidt tot talloze rij- en tabellocks, en zelfs te veel verzoeken uiteindelijk, waardoor te veel verbindingsfouten ontstaan. Door berichtwachtrijen te gebruiken, kunnen we verzoeken asynchroon verwerken, waardoor de belasting op het systeem wordt verlicht.
RabbitMQ
Het is een open source berichtenwachtrij geschreven in Erlang, die veel protocollen ondersteunt: AMQP, XMPP, SMTP, STOMP, wat het zeer zwaargewicht maakt en geschikter voor ontwikkeling op ondernemingsniveau. Het is een toonaangevende implementatie van het AMQP-protocol, dat een broker-architectuur implementeert, wat betekent dat berichten op een centrale node kunnen worden gequeued voordat ze naar de client worden gestuurd. Er is goede ondersteuning voor routering, load balancing of datapersistentie. Deze functie maakt RabbitMQ eenvoudig te gebruiken en in te zetten, geschikt voor veel scenario's zoals routering, load balancing of berichtpersistentie, en kan met slechts enkele regels code via berichtwachtrijen worden uitgevoerd. Dit maakt het echter minder schaalbaar en trager omdat de centrale node de latentie verhoogt en groter is na het inkapselen van berichten. Om RabbitMQ te configureren, moet je de Erlang-omgeving op de doelmachine installeren.
Klik om deze afbeelding in een nieuw venster te bekijken
? MQ(ZeroMQ)
Het staat bekend als het snelste systeem voor het wachtrijen van berichten, vooral voor scenario's met hoge doorvoersnelheid. Het is een zeer lichtgewicht berichtensysteem dat specifiek is ontwikkeld voor scenario's met hoge doorvoer/lage latentie en vaak te vinden is in toepassingen in de financiële wereld. In vergelijking met RabbitMQ ondersteunt ZeroMQ veel geavanceerde berichtscenario's, maar je moet individuele blokken implementeren in het ZeroMQ-framework (zoals sockets of apparaten, enzovoort).
? MQ (ZeroMQ) kan geavanceerde/complexe wachtrijen implementeren waar RabbitMQ niet goed in is, maar ontwikkelaars moeten meerdere technische frameworks zelf combineren, en de technische complexiteit vormt een uitdaging voor de succesvolle toepassing van deze MQ. ZeroMQ heeft een uniek niet-middleware model waarbij je geen berichtserver of middleware hoeft te installeren en draaien, omdat je applicatie deze servicerol zal vervullen. Het enige wat je hoeft te doen is simpelweg de ZeroMQ-bibliotheek raadplegen, die je kunt installeren met NuGet, en je kunt zonder problemen berichten tussen applicaties versturen. ZeroMQ biedt echter alleen niet-persistente wachtrijen, wat betekent dat als de machine uitvalt, de data verloren gaat. Onder hen gebruikt Twitter's Storm ZeroMQ als transmissie van datastromen. ZeroMQ is erg flexibel, maar je moet de 80 pagina's tellende handleiding leren (als je schrijft over een gedistribueerd systeem, zorg dan dat je het leest).
ZeroMQ heeft geen middleware-architectuur en vereist geen serviceprocessen en uitvoeringen. In feite speelt je applicatie-endpoint deze servicerol. Dit maakt het heel eenvoudig om in te zetten, maar het probleem is dat je nergens kunt kijken als er iets misgaat. Voor zover wij weten biedt ZeroMQ alleen niet-persistente wachtrijen aan. Je kunt je eigen audit- en dataherstelmogelijkheden implementeren waar je die nodig hebt.
Klik om deze afbeelding in een nieuw venster te bekijken
MSMQ
Dit is het enige in het product van Microsoft dat als waardevol wordt beschouwd. Als MSMQ kan bewijzen dat het dit soort taken aankan, zullen ze ervoor kiezen het te gebruiken. Het punt is dat dit niet ingewikkeld is, niets anders dan ontvangen en verzenden; Het heeft enkele harde beperkingen, zoals de maximale berichtgrootte van 4MB. Deze problemen kan echter worden opgelost door verbinding te maken met software zoals MassTransit of NServiceBus.
Klik om deze afbeelding in een nieuw venster te bekijken
Jafka/Kafka
Kafka (dat berichten verspreidt over verschillende knooppunten) is een gedistribueerd MQ-systeem ontwikkeld en open-source gemaakt door LinkedIn in december 2010, en is nu een incubatieproject van Apache, een hoogpresterend cross-language gedistribueerd Publish/Subscribe message queue-systeem, en Jafka wordt geïncubeerd bovenop Kafka, wat een verbeterde versie van Kafka is. Het heeft de volgende kenmerken: snelle persistentie, die berichten kan behouden onder de systeemoverhead van O(1); Hoge doorvoersnelheid, die op een gewone server een doorvoersnelheid van 10W/s kan bereiken; Volledig gedistribueerd systeem, Broker, Producer en Consumer ondersteunen allemaal native distributed en bereiken automatisch complex evenwicht. Ondersteunt parallelle laadmogelijkheden van Hadoop-data, wat een haalbare oplossing is voor logdata en offline analysesystemen zoals Hadoop, maar met de beperkingen van realtime verwerking. Kafka verenigt online en offline berichtverwerking via Hadoop's parallelle laadmechanisme, wat ook belangrijk is voor het systeem dat in dit onderwerp wordt bestudeerd. Apache Kafka is een zeer lichtgewicht berichtensysteem ten opzichte van ActiveMQ, en naast zeer goede prestaties is het ook een gedistribueerd systeem dat goed werkt.
Klik om deze afbeelding in een nieuw venster te bekijken
Apache ActiveMQ
ActiveMQ bevindt zich ergens tussen de twee in (RabbitMQ en ZeroMQ), vergelijkbaar met ZemoMQ, en kan zowel in proxy- als P2P-modus worden ingezet. Net als bij RabbitMQ is het eenvoudig om geavanceerde scenario's te implementeren en vereist het weinig verbruik.
ActiveMQ staat bekend als de ruggengraat van de Java-wereld. Het heeft een lange geschiedenis en wordt veel gebruikt. Het is ook cross-platform en biedt een natuurlijk integratie-toegangspunt voor producten die niet op Microsofts platform staan. Het is echter alleen mogelijk om in aanmerking te komen als het voorbij MSMQ is gelopen. Om ActiveMQ te configureren, moet je de Java-omgeving op de doelmachine installeren.
Klik om deze afbeelding in een nieuw venster te bekijken
Het is belangrijk op te merken dat het volgende generatie product van ActiveMQ Apollo is, gebaseerd op het ActiveMQ-prototype en een snellere, betrouwbaardere en gemakkelijker te onderhouden message broker-tool is. Apache noemt Apollo de snelste en meest robuuste STOMP (Streaming Text Orientated Message Protocol) server.
De kenmerken van Apollo zijn als volgt:
Stomp 1.0 en Stomp 1.1 protocollen worden ondersteund
Onderwerpen en wachtrijen
Queue Browser
Theme-persistente abonnementen
Spiegelwachtrij
Betrouwbare berichtenwisseling
Verloop van berichten en uitwisseling
Berichtenpicker
JAAS geverifieerd
ACL-gebaseerde autorisatie
Ondersteuning voor SSL/TLS en certificaatvalidatie
REST Management API
Klik om deze afbeelding in een nieuw venster te bekijken
Redis
Het is een Key-Value NoSQL-database, die actief wordt ontwikkeld en onderhouden, hoewel het een Key-Value databaseopslagsysteem is, maar het ondersteunt MQ-functies, waardoor het kan worden gebruikt als een lichtgewicht wachtrijdienst. Voor de onboarding- en out-queue-operaties van RabbitMQ en Redis, elk 1 miljoen keer, en de uitvoeringstijd wordt elke 100.000 keer geregistreerd. De testgegevens zijn verdeeld in vier verschillende groottes: 128Bytes, 512Bytes, 1K en 10K. Experimenten tonen aan dat bij het toetreden tot het team de prestaties van Redis hoger zijn dan die van RabbitMQ wanneer de datavergelijking klein is, en als de datagrootte groter is dan 10K, is Redis ondraaglijk traag. Toen Redis het team verliet, liet hij een zeer goede prestatie zien, ongeacht de omvang van de data, terwijl de prestaties van RabbitMQ veel lager waren dan die van Redis.
MemcacheQ
Persistente berichtenwachtrij Memcacheq (kortweg MCQ) is een lichte berichtenwachtrij, MemcacheQ heeft de volgende functies:
1 Eenvoudig en gemakkelijk in gebruik
2 Snelle verwerking
3 Meerdere wachtrijen
4 Goede gelijktijdige prestaties
5 Compatibel met het Memcache-protocol. Dit betekent dat je alleen de memcache-extensie moet installeren, geen extra plugins nodig zijn.
6 Het is ook handig te gebruiken in het zend-framework.
Uiteindelijk zijn deze producten:
1. Beide hebben hun eigen client-API's of ondersteunen meerdere programmeertalen;
2. Er is veel documentatie;
3. Er werd positieve ondersteuning geboden.
4. ActiveMQ, RabbitMQ, MSMQ, Redis moeten allemaal serviceprocessen starten, die kunnen worden gemonitord en geconfigureerd, en de andere zijn problematisch
5. Ze bieden allemaal relatief goede betrouwbaarheid (consistentie), schaalbaarheid en load balancing, en natuurlijk ook prestaties
Ik zal hier geen onzin uithalen, hieronder volgt een set testresultaten die van het internet zijn onderschept. Het aantal verzonden en ontvangen berichten per seconde wordt weergegeven. Het hele proces genereerde in totaal 1 miljoen 1.000 berichten. De test werd uitgevoerd op een Windows Vista standalone machine.
Zoals je ziet is ZeroMQ geen level zoals iets anders. De prestaties zijn verrassend hoog. Desondanks biedt dit product geen persistentie in berichten, kan het niet eenvoudig tussenliggende processen opslaan en monitoren, en vereist het zelfaudits en gegevensherstel, waardoor het niet bevredigend is qua gebruiksgemak en HA. De conclusie is duidelijk: als je wilt dat een app berichten zo snel mogelijk verstuurt, kies je voor ZeroMQ. Het is waardevoller als je niet te veel geeft om het kwijtraken van bepaalde berichten door toeval.
De blogger in dit artikel hoopt (en hoopt niet veel) Rabbit te gebruiken, Rabbitmq heeft ingebouwde ha, als je een cluster vormt, hoef je je geen zorgen te maken over problemen zoals load balancing, en kun je een queue mirror opzetten. Maar dit soort dingen is dat er meer getest moet worden, en je eindigt met een favoriet, en alles wat ik over Rabbit heb gehoord en gelezen doet me denken dat het de beste keuze zou moeten zijn.
|
Geplaatst op 15-12-2016 10:52:40
|
|
|
|
