Denne artikel fører først til, hvilke problemer meddelelsesmiddleware normalt skal løse, hvilke vanskeligheder der vil opstå ved at løse disse problemer, om Apache RocketMQ kan løses som en højtydende, højgennemstrømmet distribueret meddelelsesmiddleware open source af Alibaba, og hvordan disse problemer defineres i specifikationen. Denne artikel vil derefter introducere arkitekturdesignet af RocketMQ for at give læserne en hurtig forståelse af RocketMQ.
1. Hvilke problemer skal beskedmiddleware løse? Publicér/Abonner er den mest grundlæggende funktion i beskedmiddleware og er også relevant for traditionel RPC-kommunikation. Jeg vil ikke gå i detaljer her.
Den prioritet, der beskrives i Message Priority-specifikationen, refererer til en meddelelseskø; hver besked har en forskellig prioritet, typisk beskrevet med heltal, og beskeden med høj prioritet leveres først, hvis beskeden er fuldstændig i en hukommelseskø, kan den sorteres efter prioriteten før levering, så den høje prioritet leveres først.
Da alle beskeder i RocketMQ er persistente, vil overheaden være meget stor, hvis de sorteres efter prioritet, så RocketMQ understøtter ikke specifikt meddelelsesprioritet, men kan implementere lignende funktioner i en workaround, det vil sige konfigurere en kø med høj prioritet og en kø med normal prioritet og sende forskellige prioriteter til forskellige køer.
For prioriterede spørgsmål kan de opsummeres i to kategorier:
- Så længe prioriteten opnås, er det ikke en prioritet i streng forstand, og prioriteten opdeles normalt i høj, mellem, lav eller flere flere niveauer. Hver prioritet kan repræsenteres af et forskelligt emne, og når man sender en besked, angiv forskellige emner til at repræsentere prioriteten, hvilket kan løse de fleste prioritetsproblemer, men kompromittere nøjagtigheden af forretningsprioriteterne.
- Streng prioritet, prioritet udtrykkes som et heltal, såsom 0 ~ 65535, denne type prioritetsproblem egner sig generelt ikke til at blive løst med forskellige emner. Hvis du vil have MQ til at løse dette problem, vil det have en meget stor indvirkning på MQ's ydeevne. Her er et punkt for at sikre, at virksomheden virkelig har brug for denne strenge prioritering, og hvis prioriteterne komprimeres til få, hvor stor en indvirkning vil det så have på virksomheden?
Beskedrækkefølge refererer til en type besked, der kan forbruges i den rækkefølge, den sendes i. For eksempel genererer en ordre 3 beskeder, nemlig ordreoprettelse, ordrebetaling og ordreafslutning. Når man indtager, er det meningsfuldt at indtage det i denne rækkefølge. Men samtidig kan ordrer forbruges parallelt.
RocketMQ kan nøje sikre, at beskederne er ordnede.
Message FilterBroker Meddelelsesfiltrering
I Broker har filtrering efter forbrugerens krav den fordel, at det reducerer overførslen af unødvendige beskeder til forbrugeren.
Ulempen er, at det øger byrden for mægleren og er relativt komplekst at implementere.
1. Taobao Notify understøtter en række filtreringsmetoder, herunder direkte filtrering efter beskedtype og fleksibel syntaksudtryksfiltrering, som kan opfylde næsten de mest krævende filtreringsbehov.
2. Taobao RocketMQ understøtter filtrering efter simpelt beskedtag samt beskedhoved og brødtekst.
3. Fleksibel syntaksudtryksfiltrering understøttes også i CORBA Notification-specifikationen.
Forbruger-side meddelelsesfiltrering
Denne filtrering kan tilpasses fuldt ud af applikationen, men ulempen er, at mange ubrugelige beskeder sendes til forbrugeren.
Der findes flere almindelige persistensmetoder, der bruges af beskedpersistens:
- Persist i en database, såsom Mysql.
- Persist til KV-lagring, såsom levelDB, Berkeley DB og andre KV-lagringssystemer.
- Persistens i form af filposter, såsom Kafka, RocketMQ
- Lav et vedvarende billede af hukommelsesdataene, såsom beanstalkd, VisiNotify
- (1), (2) og (3) alle tre persistensmetoder har evnen til at udvide hukommelseskøbufferen, og (4) er blot et hukommelsesbillede, som stadig kan gendanne data fra den tidligere hukommelse, efter at brokeren lægger på og genstarter.
JMS- og CORBA-notifikationsspecifikationerne specificerer ikke eksplicit, hvordan den skal opretholdes, men ydeevnen af persistensdelen bestemmer direkte ydeevnen af hele meddelelsesmellemvaren.
RocketMQ udnytter fuldt ud Linux-filsystemets hukommelsescache for at forbedre ydeevnen.
Der er flere situationer, hvor beskedens pålidelighed påvirker beskedens pålidelighed:
- Mægleren lukker normalt
- Broker-krakket
- OS Crash
- Maskinen mister strøm, men strømforsyningen kan genoprettes med det samme.
- Maskinen vil ikke tænde (den kan være beskadiget på nøgleenheder som CPU, bundkort, hukommelse osv.)
- Skade på diskenheden.
(1), (2), (3) og (4) er alle situationer, hvor hardwareressourcer kan genoprettes med det samme, og RocketMQ kan sikre, at beskeder ikke går tabt, eller at en lille mængde data går tabt (afhængigt af om flashing-metoden er synkron eller asynkron).
(5) (6) Det er et enkelt fejlpunkt og kan ikke gendannes; når det først sker, går alle beskeder på dette punkt tabt. I begge tilfælde sikrer RocketMQ, at 99% af beskederne ikke går tabt gennem asynkron replikering, men der er stadig meget få beskeder, der kan gå tabt. Synkron dual write-teknologi kan fuldstændigt undgå enkeltpunkter, hvilket uundgåeligt vil påvirke ydeevnen, hvilket gør den velegnet til situationer med ekstremt høje krav til beskedpålidelighed, såsom Money-relaterede applikationer.
RocketMQ understøtter synkron dual writing fra version 3.0.
Low Latency Messaging kan nå forbrugeren straks efter, at beskeden når mægleren, uden at der ophobes beskeder.
RocketMQ bruger en lang polling pull-metode for at sikre, at beskeden er meget realtids, og at realtidsbeskeden ikke er lavere end push-beskeden.
Mindst én gang betyder, at hver besked skal leveres én gang.
RocketMQ Consumer henter først beskeden til lokalområdet og returnerer derefter ack'en til serveren, når forbruget er afsluttet.
Præcis kun én gang- Afsendelsesbeskedstadiet tillader ikke at sende dubletter beskeder.
- I Consume Message-fasen er det ikke tilladt at forbruge duplikerede beskeder.
Kun når de to ovenstående betingelser er opfyldt, kan beskeden betragtes som "Præcis kun én gang", og for at opnå ovenstående to punkter vil der uundgåeligt blive genereret enorme overhead i det distribuerede systemmiljø. Derfor garanterer RocketMQ ikke denne funktion for at opnå høj ydeevne og kræver deduplikering i virksomheden, hvilket betyder, at forbrugerbeskeder skal være idempotente. Selvom RocketMQ ikke strengt kan garantere ikke-duplikering, forekommer der under normale omstændigheder sjældent gentagne afsendelser og forbrug, kun netværksforstyrrelser, forbrugerstart og -stop samt andre unormale situationer såsom meddelelsesduplikering.
Den væsentlige årsag til dette problem er, at der er usikkerhed i netværksopkald, det vil sige den tredje tilstand af hverken succes eller fiasko, så problemet med beskedgentagelse opstår.
Hvad skal jeg gøre, hvis Broker's Buffer er fuld? Mæglerens buffer refererer normalt til hukommelsesbufferstørrelsen på en kø i mægleren, som normalt er begrænset i størrelse, hvad hvis bufferen er fuld?
Sådan håndteres det i CORBA-notifikationsspecifikationen:
- RejectNewEvents afviser den nye besked og returnerer RejectNewEvents-fejlkoden til producenten.
- Kasser eksisterende beskeder i henhold til en specifik politik
- AnyOrder - Enhver begivenhed kan kasseres ved overflow. Dette er standardindstillingen for denne egenskab.
- FifoOrder - Den første begivenhed, der modtages, er den første, der kasseres.
- LifoOrder - Den sidste begivenhed, der modtages, er den første, der kasseres.
- PriorityOrder - Begivenheder bør kasseres i prioriteret rækkefølge, således at lavere prioritet begivenheder kasseres før højere prioritet.
- DeadlineOrder - Begivenheder bør kasseres i rækkefølgen efter kortest udløbsfrist først.
RocketMQ har ikke konceptet hukommelsesbuffer, og køerne i RocketMQ er persistente diske, og dataene slettes regelmæssigt.
For løsningen på dette problem har RocketMQ en meget væsentlig forskel fra andre MQ'er; RocketMQ's hukommelsesbuffer er abstraheret til en uendelig lang kø, uanset hvor meget data der kommer ind, kan den installeres, denne uendelighed er forudset, mægleren vil regelmæssigt slette udløbne data, for eksempel gemmer mægleren kun 3 dages beskeder, og selvom bufferens længde er uendelig, vil dataene fra 3 dage siden blive slettet fra slutningen af køen.
Retrospektivt forbrug refererer til det budskab, som forbrugeren med succes har indtaget, og budskabet skal genforbruges på grund af virksomhedens efterspørgsel. For eksempel, på grund af fejl i forbrugersystemet, skal dataene fra for 1 time siden genbruges efter genoprettelse, hvorefter mægleren skal levere en mekanisme til at tilbagelægge forbrugsprogressionen i henhold til tidsdimensionen.
RocketMQ understøtter retrospektivt forbrug baseret på tid med en tidsdimension nøjagtig på millisekunder, som kan spores frem eller tilbage.
Hovedfunktionen i message stacking message middleware er asynkron decoupling, og en anden vigtig funktion er at blokere dataflood-peaken i front-end og sikre stabiliteten i back-end systemet, hvilket kræver, at message middleware har en vis message stacking-evne, og message heap integrerer følgende to situationer:
- Beskeder ophobes i hukommelsesbuffere, og når de overstiger hukommelsesbufferen, kan meddelelser droppes i henhold til en bestemt drop-politik, som beskrevet i CORBA Notification specifikationen. Den er velegnet til tjenester, der kan tolerere kassering af beskeder; i dette tilfælde ligger akkumuleringskapaciteten af beskeder hovedsageligt i størrelsen af hukommelsesbufferen, og ydelsesforringelsen vil ikke være for stor efter beskedens stakk, fordi mængden af data i hukommelsen har begrænset indflydelse på adgangsmuligheden for omverdenen.
- Beskeder er stablet i persistente lagringssystemer såsom DB, KV-lager, filpostform. Når beskeder ikke kan rammes i hukommelsescachen, er det uundgåeligt at få adgang til disken, hvilket vil generere en stor mængde læse-IO, og gennemstrømningen af læse-IO bestemmer direkte adgangsevnen for beskeder, efter de er hobet op.
Der er fire hovedpunkter til at evaluere evnen til at samle beskeder:
- Hvor mange beskeder kan stables, hvor mange bytes? Det vil sige bunkekapaciteten af beskeden.
- Når en besked er stablet op, påvirkes så gennemstrømningen af beskeden af stakkingen?
- Vil forbrugernes normale forbrug blive påvirket, når budskaberne hober sig op?
- Når beskederne er samlet op, hvad er så gennemstrømningen, når man tilgår beskeder, der er samlet på disken?
Distribuerede transaktioner Flere kendte distribuerede transaktionsspecifikationer, såsom XA, JTA osv. Blandt dem understøttes XA-specifikationen bredt af store databaseleverandører som Oracle, Mysql osv. Blandt dem er XAs TM-implementeringsleder som Oracle Tuxedo bredt anvendt inden for finans, telekommunikation og andre områder.
Distribuerede transaktioner involverer to-trins commit-problemer, og hvad angår datalagring, skal KV-lagring understøttes, fordi det andet trin i commit rollback skal ændre beskedens tilstand, hvilket skal involvere handlingen at finde beskeden i henhold til nøglen. RocketMQ omgår problemet med at finde beskeden i henhold til nøglen i andet trin, ved at bruge første trin til at sende den forberedte besked, få offsetet af beskeden, og andet trin til at tilgå beskeden gennem offset og ændre tilstanden; offsetet er dataadressen.
RocketMQ's transaktionsimplementeringsmetode udføres ikke via KV-lagring, men gennem offset-metoden, som har en væsentlig fejl, nemlig at ændring af data via offset vil forårsage for mange beskidte sider i systemet, hvilket kræver særlig opmærksomhed.
Planlagte beskeder Skemalagte beskeder betyder, at beskeder ikke kan forbruges af forbrugere umiddelbart efter, de er sendt til mægleren, og kun kan forbruges på et bestemt tidspunkt eller efter ventetid på et bestemt tidspunkt.
Hvis du vil understøtte vilkårlig tidsnøjagtighed på mæglerniveau, skal du lave beskedsortering, og hvis der er persistens, vil meddelelsessortering uundgåeligt medføre store performance-overhead.
RocketMQ understøtter timing-beskeder, men understøtter ikke vilkårlig tidsnøjagtighed og understøtter specifikke niveauer, såsom timing 5s, 10s, 1m osv.
Beskedgenprøv Efter at forbrugeren ikke kan modtage beskeden, skal der gives en genforsøgsmekanisme, så beskeden kan forbruges igen. Fejl i forbrugerens forbrugsbeskeder kan normalt betragtes i følgende situationer:
- På grund af selve beskedens årsag, såsom deserialiseringsfejl, kan beskeddataene ikke behandles (såsom opladning af telefonregningen, mobilnummeret på den aktuelle besked er logget ud, kan ikke genoplades) osv. Denne fejl kræver normalt, at man springer denne besked over og forbruger andre beskeder, og denne mislykkede besked er 99% mislykket, selv hvis forbruget forsøges igen med det samme, så det er bedst at tilbyde en tidsbegrænset genprøvemekanisme, det vil sige at prøve igen efter 10 sekunder.
- Fordi de afhængige downstream applikationstjenester ikke er tilgængelige, såsom at DB-forbindelsen ikke er tilgængelig, det eksterne systemnetværk er utilgængeligt osv. Når denne fejl opstår, vil andre beskeder også blive forbrugt, selv hvis den nuværende fejlmeddelelse springes over. I dette tilfælde anbefales det at anvende sleep 30s og modtage den næste besked, hvilket kan mindske presset på mægleren for at prøve beskeden igen.
Oversigt over RocketMQLad os finde ud af, om RocketMQ løser de problemer, som den ovennævnte meddelelsesmiddleware står overfor.
Hvad er RocketMQ?
Figuren ovenfor er en typisk model for beskedmiddleware, der sender og modtager beskeder, RocketMQ er også designet på denne måde, kort sagt har RocketMQ følgende egenskaber:
- Det er en kømodel-meddelelsesmiddleware med høj ydeevne, høj pålidelighed, høj realtids- og distribuerede egenskaber.
- Producer, Consumer og Queue kan alle distribueres.
- Producer sender beskeder til nogle køer på skift, køsamlingen kaldes Topic, Consumer Hvis broadcast forbrug, forbruger én forbrugerinstans alle køer, der svarer til dette emne, og hvis klyngeforbrug, forbruger flere forbrugerinstanser køsamlingen tilsvarende emne jævnt.
- Streng beskedrækkefølge kan garanteres
- Tilbyder rige besked-pull-tilstande
- Effektive horisontale abonnentskaleringsmuligheder
- Real-time beskedabonnementsmekanisme
- Hundredvis af millioner af beskeder akkumulerer kapacitet
- Mindre afhængighed
RocketMQ fysisk udrulningsstruktur
Som vist i figuren ovenfor har RocketMQ's udrulningsstruktur følgende karakteristika:
- Navneserver er en næsten stateless node, der kan implementeres i klynger uden nogen informationssynkronisering mellem noder.
- Udrulningen af Broker er relativt kompleks, Broker er opdelt i Master og Slave, en Master kan svare til flere Slaves, men en Slave kan kun svare til én Master, korrespondancen mellem Master og Slave defineres ved at angive samme BrokerName, forskellig BrokerId, BrokerId er 0 for Master, og ikke-0 betyder Slave. Masters kan også udsendes i flere grupper. Hver mægler etablerer en lang forbindelse med alle noder i Name Server-klyngen og registrerer emneinformation til alle Name Servere med jævne mellemrum.
- Producenten etablerer en lang forbindelse med en af noderne i Name Server-klyngen (tilfældigt udvalgt), henter periodisk emne-routinginformation fra Name Serveren, etablerer en lang forbindelse til masteren, der leverer topic-tjenesten, og sender hjerteslag til masteren med jævne mellemrum. Producer er fuldstændig stateless og kan implementeres i klynger.
- Forbrugeren etablerer en lang forbindelse med en af noderne i Name Server-klyngen (tilfældigt udvalgt), henter regelmæssigt emne-routinginformation fra Name Serveren og etablerer en lang forbindelse til Master og Slave, som leverer topic-tjenesten, og sender hjerteslag til Master og Slave med jævne mellemrum. Forbrugere kan abonnere på beskeder fra både Master og Slave, og abonnementsreglerne bestemmes af Broker-konfigurationen.
RocketMQ logisk udrulningsstruktur
Som vist i figuren ovenfor har den logiske implementeringsstruktur af RocketMQ to karakteristika: Producent og Forbruger.
Brugt til at repræsentere en beskedapplikation indeholder en Producer Group flere Producer-instanser, som kan være flere maskiner, flere processer på en maskine eller flere Producer-objekter i en proces. En Producer Group kan sende flere Topic-beskeder, og Producer Group fungerer som følger:
- Identificer en type producent
- Du kan forespørge, at der er flere Producer-instanser i denne beskedapplikation via O&M-værktøjet
- Når en distribueret transaktionsbesked sendes og producenten går ned uventet, vil mægleren aktivt kalde enhver maskine i producentgruppen tilbage for at bekræfte transaktionsstatus.
Brugt til at repræsentere en forbrugerbeskedapplikation indeholder en forbrugergruppe flere forbrugerinstanser, som kan være flere maskiner, flere processer eller flere forbrugerobjekter i en proces. Flere forbrugere i en forbrugergruppe forbruger beskeder på en jævnt fordelt måde, og hvis de sættes til at udsende, forbruger hver instans under denne forbrugergruppe hele mængden af data.
RocketMQ datalagringsstruktur
Som vist i figuren ovenfor anvender RocketMQ en lagringsmetode, der adskiller data fra indekser. Effektivt reducere tabet af filressourcer, IO-ressourcer og hukommelsesressourcer. Selv med massive data som Alibaba kan scenarier med høj samtidighed effektivt reducere end-to-end latenstid og have stærke horisontale skaleringsmuligheder.
|
Opslået på 28/07/2017 20.26.52
|
|
|
|
Opslået på 29/07/2017 08.09.37