Dit artikel leidt eerst naar welke problemen berichtmiddleware gewoonlijk moet oplossen, welke moeilijkheden er zullen worden tegengekomen bij het oplossen van deze problemen, of Apache RocketMQ kan worden opgelost als een high-performance, high-throughput distributed message middleware open source van Alibaba, en hoe deze problemen in de specificatie worden gedefinieerd. Dit artikel zal vervolgens het architectuurontwerp van RocketMQ introduceren, zodat lezers snel inzicht krijgen in RocketMQ.
1. Welke problemen moet berichtmiddleware oplossen? Publiceren/Abonneeren is de meest basale functie van message middleware en is ook vergeleken met traditionele RPC-communicatie. Ik zal hier niet in detail treden.
De prioriteit die in de Message Priority-specificatie wordt beschreven, verwijst naar een berichtwachtrij; elk bericht heeft een andere prioriteit, meestal beschreven door gehele getallen; het bericht met hoge prioriteit wordt als eerste afgeleverd; als het bericht volledig in een geheugenwachtrij zit, kan het worden gesorteerd op basis van de prioriteit vóór levering, zodat de hoge prioriteit als eerste wordt afgeleverd.
Aangezien alle berichten in RocketMQ persistent zijn, zal de overhead zeer groot zijn als ze op prioriteit worden gesorteerd, dus ondersteunt RocketMQ niet specifiek berichtprioriteit, maar kan vergelijkbare functies implementeren in een workaround, dat wil zeggen het configureren van een wachtrij met een hoge prioriteit en een wachtrij met een normale prioriteit, en het sturen van verschillende prioriteiten naar verschillende wachtrijen.
Voor prioriteitskwesties kunnen ze worden samengevat in 2 categorieën:
- Zolang de prioriteit wordt bereikt, is het geen prioriteit in strikte zin, en wordt de prioriteit meestal verdeeld in hoog, middel, laag of meerdere niveaus. Elke prioriteit kan worden weergegeven door een ander onderwerp, en bij het verzenden van een bericht specificeer je verschillende onderwerpen om de prioriteit te vertegenwoordigen, wat de meeste prioriteitsproblemen kan oplossen, maar de nauwkeurigheid van bedrijfsprioriteiten kan ondermijnen.
- Strikte prioriteit, prioriteit wordt uitgedrukt als een geheel getal, zoals 0 ~ 65535, dit soort prioriteitsprobleem is over het algemeen niet geschikt om met verschillende onderwerpen op te lossen. Als je wilt dat MQ dit probleem oplost, heeft dat een grote impact op de prestaties van MQ. Hier is een punt om ervoor te zorgen dat het bedrijf deze strikte prioritering echt nodig heeft, en als de prioriteiten worden samengeperst tot een paar punten, hoeveel impact zal dat dan op het bedrijf hebben?
Bericht Order verwijst naar een type bericht dat in de volgorde waarin het wordt verzonden kan worden geconsumeerd. Een bestelling genereert bijvoorbeeld 3 berichten, namelijk ordercreatie, orderbetaling en orderafronding. Bij het consumeren is het zinvol om in deze volgorde te consumeren. Maar tegelijkertijd kunnen bestellingen parallel worden geconsumeerd.
RocketMQ kan strikt garanderen dat berichten ordelijk zijn.
Message FilterBroker Berichtfiltering
Bij Broker heeft filteren volgens de behoeften van de consument het voordeel dat het de overdracht van onnodige berichten naar de consument vermindert.
Het nadeel is dat het de last voor de makelaar verhoogt en relatief complex is om te implementeren.
1. Taobao Notify ondersteunt een verscheidenheid aan filtermethoden, waaronder directe filtering op berichttype en flexibele syntaxis-expressiefiltering, die bijna aan de meest veeleisende filterbehoeften kan voldoen.
2. Taobao RocketMQ ondersteunt filtering op basis van eenvoudige Message Tag, evenals Message Header en body.
3. Flexibele syntaxisexpressiefiltering wordt ook ondersteund in de CORBA Notification specificatie.
Berichtfiltering aan consumentenzijde
Deze filtering kan volledig worden aangepast door de applicatie, maar het nadeel is dat er veel nutteloze berichten naar de consument worden gestuurd.
Er zijn verschillende veelgebruikte persistentiemethoden die door berichtpersistentie worden gebruikt:
- Blijf in een database, zoals Mysql.
- Persist op KV-opslag, zoals levelDB, Berkeley DB en andere KV-opslagsystemen.
- Persistentie in de vorm van bestandsgegevens, zoals Kafka, RocketMQ
- Maak een behouden image van de geheugengegevens, zoals beanstalkd, VisiNotify
- (1), (2) en (3) alle drie de persistentiemethoden kunnen de geheugenwachtrijbuffer uitbreiden, en (4) zijn slechts een geheugenafbeelding, die de gegevens uit het vorige geheugen nog steeds kan herstellen nadat de broker is opgehangen en opnieuw is opgestart.
De JMS- en CORBA-notificatiespecificaties specificeren niet expliciet hoe te behouden blijven, maar de prestaties van het persistentiegedeelte bepalen direct de prestaties van de gehele berichtmiddleware.
RocketMQ maakt volledig gebruik van de geheugencache van het Linux-bestandssysteem om de prestaties te verbeteren.
Er zijn verschillende situaties waarin de betrouwbaarheid van berichten de betrouwbaarheid van berichten beïnvloedt:
- Makelaar sluit normaal
- Brokercrash
- OS Crash
- De machine verliest stroom, maar de stroomvoorziening kan direct worden hersteld.
- De machine gaat niet aan (hij kan beschadigd raken aan belangrijke apparaten zoals CPU, moederbord, geheugen, enzovoort).
- Schade aan schijfapparaat.
(1), (2), (3) en (4) zijn allemaal situaties waarin hardwarebronnen onmiddellijk kunnen worden hersteld, en RocketMQ kan ervoor zorgen dat berichten niet verloren gaan of dat er een kleine hoeveelheid data verloren gaat (afhankelijk van of de flashingmethode synchroon of asynchroon is).
(5) (6) Het is een enkel punt van storing en kan niet worden hersteld; zodra het gebeurt, zijn alle berichten op dit ene punt verloren. In beide gevallen zorgt RocketMQ ervoor dat 99% van de berichten niet verloren gaat door asynchrone replicatie, maar er zijn nog steeds zeer weinig berichten die verloren kunnen gaan. Synchrone dual write-technologie kan single points volledig vermijden, wat onvermijdelijk de prestaties zal beïnvloeden, waardoor het geschikt is voor situaties met extreem hoge berichtbetrouwbaarheidseisen, zoals Money-gerelateerde toepassingen.
RocketMQ ondersteunt synchroon dual writing vanaf versie 3.0.
Low Latency Messaging kan de consument direct bereiken nadat het bericht de broker heeft bereikt, zonder dat er berichten worden opgebouwd.
RocketMQ gebruikt een long polling pull-methode om ervoor te zorgen dat het bericht zeer real-time is, en dat het real-time bericht niet lager is dan dat van push.
Minstens één keer betekent dat elk bericht één keer moet worden afgeleverd.
RocketMQ Consumer haalt eerst het bericht naar het lokale gebied en stuurt daarna de ack terug naar de server nadat het verbruik is voltooid.
Precies maar één keer- De verzendingsfase van berichten staat het versturen van dubbele berichten niet toe.
- In de fase Consume Message mogen dubbele berichten niet worden gebruikt.
Alleen wanneer aan bovenstaande twee voorwaarden is voldaan, kan het bericht als "Precies Slechts Eén Keer" worden beschouwd, en om bovenstaande twee punten te bereiken, zal er onvermijdelijk enorme overhead ontstaan in de gedistribueerde systeemomgeving. Daarom garandeert RocketMQ deze functie niet om hoge prestaties na te streven en vereist het deduplicatie in het bedrijf, wat betekent dat consumentenberichten idempotent moeten zijn. Hoewel RocketMQ geen strikte garantie kan geven op niet-duplicatie, zijn er onder normale omstandigheden zelden herhaald verzenden en verbruiken, alleen netwerkafwijkingen, consumentenstart en -stop, en andere abnormale situaties zoals meldingsduplicatie.
De belangrijkste reden voor dit probleem is dat er onzekerheid is in netwerkgesprekken, dat wil zeggen de derde staat van noch succes noch falen, waardoor het probleem van berichtherhaling zich voordoet.
Wat moet ik doen als de Broker's Buffer vol is? De buffer van de broker verwijst meestal naar de grootte van de geheugenbuffer van een wachtrij in de broker, die meestal beperkt is, wat als de buffer vol is?
Zo wordt het afgehandeld in de CORBA-meldingsspecificatie:
- RejectNewEvents wijst het nieuwe bericht af en geeft de foutcode RejectNewEvents terug aan de Producer.
- Gooi bestaande berichten weg volgens een specifiek beleid
- AnyOrder - Elke gebeurtenis kan worden weggegooid bij overflow. Dit is de standaardinstelling voor deze eigenschap.
- FifoOrder - Het eerste event dat wordt ontvangen, wordt als eerste afgeworpen.
- LifoOrder - Het laatste event dat wordt ontvangen, is het eerste dat wordt afgegooid.
- PriorityOrder - Gebeurtenissen moeten in prioriteitsvolgorde worden verwijderd, zodat gebeurtenissen met lagere prioriteit worden verwijderd vóór gebeurtenissen met hogere prioriteit.
- DeadlineOrder - Gebeurtenissen moeten eerst worden verwijderd in de volgorde van de kortste vervaldatum.
RocketMQ heeft niet het concept van geheugenbuffer, en de wachtrijen van RocketMQ zijn persistente schijven, waarbij de gegevens regelmatig worden gewist.
Voor de oplossing van dit probleem heeft RocketMQ een zeer significant verschil met andere MQ's: de geheugenbuffer van RocketMQ is geabstraheerd tot een wachtrij van oneindige lengte, ongeacht hoeveel data er binnenkomt, kan deze worden geïnstalleerd, deze oneindigheid is geïnstalleerd, de broker verwijdert regelmatig verlopen data, bijvoorbeeld, de broker slaat slechts 3 dagen aan berichten op, en hoewel de lengte van deze buffer oneindig is, worden de gegevens van 3 dagen geleden verwijderd van het einde van de wachtrij.
Retrospectieve consumptie verwijst naar de boodschap die de consument succesvol heeft opgenomen, en die boodschap moet opnieuw worden geconsumeerd vanwege de vraag van het bedrijf. Bijvoorbeeld, vanwege het falen van het consumentensysteem moeten de gegevens van een uur geleden na herstel opnieuw worden gebruikt, waarna de broker een mechanisme moet bieden om de voortgang van het verbruik terug te draaien volgens de tijdsdimensie.
RocketMQ ondersteunt retrospectief verbruik gebaseerd op tijd, met een tijdsdimensie die nauwkeurig is tot milliseconden, die kan worden teruggedraaid naar voren of achteruit.
De belangrijkste functie van message stacking message middleware is asynchrone decoupling, en een andere belangrijke functie is het blokkeren van de data flood peak van de front-end en het waarborgen van de stabiliteit van het back-end systeem, wat vereist dat de message middleware een bepaalde message stacking-capaciteit heeft, en de message heap integreert de volgende twee situaties:
- Berichten worden opgestapeld in geheugenbuffers, en zodra ze de geheugenbuffer overschrijden, kunnen berichten worden verwijderd volgens een bepaald dropbeleid, zoals beschreven in de CORBA Notification specification. Het is geschikt voor services die het afsluiten van berichten kunnen verdragen; in dit geval ligt de accumulatiecapaciteit van berichten vooral in de grootte van de geheugenbuffer, en de prestatievermindering zal niet al te groot zijn nadat het bericht is gestapeld, omdat de hoeveelheid data in het geheugen een beperkte invloed heeft op de toegankelijkheid die aan de buitenwereld wordt geboden.
- Berichten worden opgestapeld in persistente opslagsystemen zoals DB, KV-opslag, bestandsrecordvorm. Wanneer berichten niet in de geheugencache kunnen worden bereikt, is het onvermijdelijk om toegang te krijgen tot de schijf, wat een grote hoeveelheid lees-IO zal genereren, en de doorvoer van lees-IO bepaalt direct de toegankelijkheid van berichten nadat ze zijn opgestapeld.
Er zijn vier hoofdpunten om het vermogen om berichten te accumuleren te evalueren:
- Hoeveel berichten kunnen worden opgestapeld, hoeveel bytes? Dat wil zeggen, de heapcapaciteit van het bericht.
- Nadat een bericht is opgestapeld, wordt de doorvoer van het bericht beïnvloed door de stapeling?
- Zal de normale consumptie van consumenten worden beïnvloed nadat de boodschappen zich opstapelen?
- Nadat de berichten zijn opgestapeld, wat is dan de doorvoer bij het benaderen van berichten die op de schijf zijn opgestapeld?
Gedistribueerde transacties Verschillende bekende specificaties voor gedistribueerde transacties, zoals XA, JTA, enzovoort. Onder hen wordt de XA-specificatie breed ondersteund door grote databaseleveranciers, zoals Oracle, Mysql, enzovoort. Onder hen wordt XA's TM-implementatieleider zoals Oracle Tuxedo veel gebruikt in financiën, telecommunicatie en andere sectoren.
Gedistribueerde transacties bevatten tweestapscommitproblemen, en qua gegevensopslag moet KV-opslag worden ondersteund, omdat de tweede fase van commit rollback de berichtstatus moet wijzigen, wat de handeling moet inhouden om het bericht te vinden volgens de sleutel. RocketMQ omzeilt het probleem van het vinden van het bericht volgens de sleutel in de tweede trap, waarbij de eerste trap het voorbereide bericht verzendt, de offset van het bericht wordt verlangd, en de tweede trap toegang krijgt tot het bericht via de offset en de toestand aanpast; de offset is het adres van de data.
De transactie-implementatiemethode van RocketMQ wordt niet uitgevoerd via KV-opslag, maar via de offset-methode, die een aanzienlijk nadeel heeft, namelijk dat het wijzigen van data via offset te veel vuile pagina's in het systeem veroorzaakt, wat speciale aandacht vereist.
Geplande berichten Geplande berichten betekenen dat berichten niet direct na verzending aan de broker door consumenten kunnen worden geconsumeerd, en alleen op een specifiek tijdstip of na het afwachten van een bepaald tijdstip.
Als je willekeurige tijdsnauwkeurigheid op brokerniveau wilt ondersteunen, moet je berichten sorteren, en als persistentie betrokken is, zal berichtsortering onvermijdelijk enorme prestatiekosten met zich meebrengen.
RocketMQ ondersteunt timingberichten, maar ondersteunt geen willekeurige tijdsnauwkeurigheid en ondersteunt specifieke niveaus, zoals timing 5s, 10s, 1m, enzovoort.
Bericht herhalen Nadat de consument het bericht niet kan consumeren, bied een herkansingsmechanisme om het bericht opnieuw te laten consumeren. Consumentenconsumptieberichten kunnen meestal worden beschouwd in de volgende situaties:
- Door de reden van het bericht zelf, zoals een deserialisatiefout, kan de berichtgegevens zelf niet worden verwerkt (zoals het opladen van de telefoonrekening, het mobiele nummer van het huidige bericht is uitgelogd, kan niet worden opgeladen), enzovoort. Deze fout vereist meestal dat je dit bericht overslaat en andere berichten consumeert, en dit mislukte bericht is 99% onsuccesvol, zelfs als de consumptie direct opnieuw wordt geprobeerd, dus het is het beste om een getimed herkansingsmechanisme te bieden, dat wil zeggen, opnieuw proberen na 10 seconden.
- Omdat de afhankelijke downstream applicatiediensten niet beschikbaar zijn, zoals dat de DB-verbinding niet beschikbaar is, het externe systeemnetwerk onbereikbaar is, enzovoort. Bij het tegenkomen van deze fout worden ook andere berichten gebruikt als het huidige mislukte bericht wordt overgeslagen. In dat geval wordt aanbevolen om slaap 30 seconden toe te passen en het volgende bericht te consumeren, wat de druk op de broker om het bericht opnieuw te proberen kan verminderen.
Overzicht van RocketMQLaten we uitzoeken of RocketMQ de problemen oplost waarmee de hierboven genoemde berichtmiddleware wordt geconfronteerd.
Wat is RocketMQ?
De bovenstaande figuur is een typisch model van berichtmiddleware die berichten verzendt en ontvangt; RocketMQ is ook op deze manier ontworpen; kortom, RocketMQ heeft de volgende kenmerken:
- Het is een queue-model berichtmiddleware met hoge prestaties, hoge betrouwbaarheid, hoge realtime en gedistribueerde eigenschappen.
- Producer, Consument en Queue kunnen allemaal worden verdeeld.
- De producent stuurt op zijn beurt berichten naar sommige wachtrijen, de wachtrijverzameling wordt Topic, Consumer genoemd. Als broadcast consumption is, consumeert één consumenteninstantie alle wachtrijen die bij dit onderwerp horen, en bij clusterconsumptie verbruiken meerdere consumenteninstanties de wachtrijverzameling die bij dit onderwerp hoort.
- Strikte berichtvolgorde kan worden gegarandeerd
- Biedt rijke bericht-pull-modi
- Efficiënte horizontale abonneeschaalmogelijkheden
- Real-time berichtabonnementsmechanisme
- Honderden miljoenen berichten kunnen worden opgebouwd.
- Minder afhankelijkheid
RocketMQ fysieke uitrolstructuur
Zoals weergegeven in de bovenstaande figuur, heeft de inzetstructuur van RocketMQ de volgende kenmerken:
- Name Server is een vrijwel stateless node die in clusters kan worden ingezet zonder enige informatiesynchronisatie tussen nodes.
- De inzet van Broker is relatief complex, Broker is verdeeld in Master en Slave, een Master kan corresponderen met meerdere Slaves, maar een Slave kan maar met één Master corresponderen, de correspondentie tussen Master en Slave wordt gedefinieerd door dezelfde BrokerName, een andere BrokerId te specificeren, BrokerId is 0 voor Master, en niet-0 betekent Slave. Masters kunnen ook in meerdere inzetstukken worden ingezet. Elke broker legt een lange verbinding tot stand met alle knooppunten in het Name Server-cluster en registreert onderwerpinformatie op regelmatige intervallen aan alle Name Servers.
- De producer legt een lange verbinding met een van de nodes in de Name Server-cluster (willekeurig geselecteerd), haalt periodiek topicrouteringsinformatie op van de Name Server, legt een lange verbinding met de master die de topicservice levert, en stuurt op regelmatige intervallen hartslagen naar de master. Producer is volledig stateless en kan in clusters worden ingezet.
- De consument legt een lange verbinding met een van de knooppunten in het Name Server-cluster (willekeurig geselecteerd), haalt regelmatig topicrouteringsinformatie op van de Name Server, en legt een lange verbinding met de Master en Slave die de topicservice leveren, en stuurt op regelmatige intervallen hartslagen naar de Master en Slave. Consumenten kunnen zich abonneren op berichten van zowel Master als Slave, en de abonnementsregels worden bepaald door de Broker-configuratie.
RocketMQ logische implementatiestructuur
Zoals te zien is in de bovenstaande figuur, heeft de logische implementatiestructuur van RocketMQ twee kenmerken: producent en consument.
Gebruikt om een berichtenapplicatie weer te geven, bevat een Producer Group meerdere Producer-instanties, die meerdere machines, meerdere processen van een machine of meerdere Producer-objecten van een proces kunnen zijn. Een Producer Group kan meerdere Topic-berichten sturen, en de Producer Group functioneert als volgt:
- Identificeer een type producent
- Je kunt via de O&M-tool opvragen dat er meerdere Producer-instanties in deze berichtenapplicatie zijn
- Bij het verzenden van een gedistribueerd transactiebericht, als de producer onverwacht uitvalt, roept de broker actief elke machine in de producer-groep terug om de transactiestatus te bevestigen.
Gebruikt om een consumentenberichtenapplicatie te representeren, bevat een consumentengroep meerdere consumenteninstanties, die meerdere machines, meerdere processen of meerdere consumentenobjecten van een proces kunnen zijn. Meerdere consumenten in een consumentengroep consumeren berichten gelijkmatig verdeeld, en als ze op uitzending staan, verbruikt elke instantie onder deze consumentengroep de volledige hoeveelheid data.
RocketMQ gegevensopslagstructuur
Zoals te zien is in de bovenstaande figuur, gebruikt RocketMQ een opslagmethode die data scheidt van indexen. Effectief het verlies van bestandsbronnen, IO-bronnen en geheugenbronnen verminderen. Zelfs met enorme data zoals Alibaba kunnen scenario's met hoge gelijktijdigheid de end-to-end latentie effectief verminderen en sterke horizontale schaalmogelijkheden bieden.
|
Geplaatst op 28-07-2017 20:26:52
|
|
|
|
Geplaatst op 29-07-2017 08:09:37