Denne artikkelen leder først til hvilke problemer meldingsmellomvare vanligvis må løse, hvilke vanskeligheter som vil oppstå ved å løse disse problemene, om Apache RocketMQ kan løses som en høyytelses, høygjennomstrømt distribuert meldingsmellomvare åpen kildekode av Alibaba, og hvordan disse problemene defineres i spesifikasjonen. Denne artikkelen vil deretter introdusere arkitekturdesignet til RocketMQ, for å gi leserne en rask forståelse av RocketMQ.
1. Hvilke problemer må meldingsmellomvare løse? Publish/Subscribe er den mest grunnleggende funksjonen i meldingsmellomvare og er også relativ til tradisjonell RPC-kommunikasjon. Jeg skal ikke gå i detalj her.
Prioriteten beskrevet i Message Priority-spesifikasjonen refererer til en meldingskø, hver melding har en forskjellig prioritet, vanligvis beskrevet med heltall, meldingen med høy prioritet leveres først, hvis meldingen er fullstendig i en minnekø, kan den sorteres etter prioriteten før levering, slik at den høye prioriteten leveres først.
Siden alle meldinger i RocketMQ er persistente, vil overheaden være svært stor hvis de sorteres etter prioritet, så RocketMQ støtter ikke spesifikt meldingsprioritet, men kan implementere lignende funksjoner i en løsning, det vil si å konfigurere en kø med høy prioritet og en kø med normal prioritet, og sende forskjellige prioriteringer til forskjellige køer.
For prioriterte saker kan de oppsummeres i to kategorier:
- Så lenge prioriteten oppnås, er det ikke en prioritet i streng forstand, og prioriteten deles vanligvis inn i høy, middels, lav eller flere nivåer. Hver prioritet kan representeres av et annet tema, og når du sender en melding, spesifiser du forskjellige emner for å representere prioriteten, noe som kan løse de fleste prioritetsproblemene, men kompromittere nøyaktigheten av forretningsprioritetene.
- Streng prioritet, prioritet uttrykkes som et heltall, for eksempel 0 ~ 65535, denne typen prioritetsproblem egner seg vanligvis ikke til å løses med ulike emner. Hvis du vil at MQ skal løse dette problemet, vil det ha stor innvirkning på MQs ytelse. Her er et poeng for å sørge for at virksomheten virkelig trenger denne strenge prioriteringen, og hvis prioriteringene komprimeres til noen få, hvor stor innvirkning vil det ha på virksomheten?
Meldingsrekkefølge refererer til en type melding som kan konsumeres i den rekkefølgen den sendes i. For eksempel genererer en ordre 3 meldinger, nemlig ordreopprettelse, ordrebetaling og fullføring av ordre. Når man spiser, er det meningsfullt å konsumere i denne rekkefølgen. Men samtidig kan bestillinger konsumeres parallelt.
RocketMQ kan strengt sørge for at meldingene er ordnede.
Message FilterBroker Meldingsfiltrering
I Broker har filtrering etter forbrukerens behov fordelen av å redusere overføringen av unødvendige meldinger til forbrukeren.
Ulempen er at det øker byrden for megleren og er relativt komplekst å implementere.
1. Taobao Notify støtter en rekke filtreringsmetoder, inkludert direkte filtrering etter meldingstype og fleksibel syntaksuttrykksfiltrering, som kan dekke nesten de mest krevende filtreringsbehovene.
2. Taobao RocketMQ støtter filtrering etter enkel meldingstag, samt meldingshode og brødtekst.
3. Fleksibel syntaksuttrykksfiltrering støttes også i CORBA Notification-spesifikasjonen.
Meldingsfiltrering på forbrukersiden
Denne filtreringen kan tilpasses fullt ut av applikasjonen, men ulempen er at mange unyttige meldinger sendes til forbrukeren.
Det finnes flere vanlige persistensmetoder som brukes av meldingspersistens:
- Persister i en database, som Mysql.
- Persister til KV-lagring, som levelDB, Berkeley DB og andre KV-lagringssystemer.
- Persistens i form av filposter, som Kafka, RocketMQ
- Lag et bevart bilde av minnedataene, for eksempel beanstalkd, VisiNotify
- (1), (2) og (3) alle tre persistensmetodene har mulighet til å utvide minnekøbufferen, og (4) er bare et minnebilde, som fortsatt kan gjenopprette data fra forrige minne etter at megleren legger på og starter på nytt.
JMS- og CORBA-notification-spesifikasjonene spesifiserer ikke eksplisitt hvordan den skal opprettholdes, men ytelsen til persistensdelen bestemmer direkte ytelsen til hele meldingsmellomvaren.
RocketMQ utnytter Linux-filsystemets minnecache fullt ut for å forbedre ytelsen.
Det finnes flere situasjoner der meldingens pålitelighet påvirker meldingens pålitelighet:
- Megleren avslutter normalt
- Meglerkrasjet
- OS-krasj
- Maskinen mister strøm, men strømforsyningen kan gjenopprettes umiddelbart.
- Maskinen vil ikke slå seg på (den kan bli skadet på viktige enheter som CPU, hovedkort, minne osv.)
- Skade på diskenheten.
(1), (2), (3) og (4) er alle situasjoner hvor maskinvareressurser kan gjenopprettes umiddelbart, og RocketMQ kan sikre at meldinger ikke går tapt eller at en liten mengde data går tapt (avhengig av om flashingsmetoden er synkron eller asynkron).
(5) (6) Det er et enkelt feilpunkt og kan ikke gjenopprettes; når det først skjer, går alle meldinger på dette punktet tapt. I begge tilfeller sikrer RocketMQ at 99 % av meldingene ikke går tapt gjennom asynkron replikering, men det er fortsatt svært få meldinger som kan gå tapt. Synkron dual write-teknologi kan fullstendig unngå enkeltpunkter, noe som uunngåelig vil påvirke ytelsen, og dermed egnet for situasjoner med ekstremt høye krav til meldingspålitelighet, som Money-relaterte applikasjoner.
RocketMQ støtter synkron dobbel skriving fra versjon 3.0.
Meldinger med lav latens kan nå forbrukeren umiddelbart etter at meldingen når megleren, uten at meldingene samles opp.
RocketMQ bruker en lang polling pull-metode for å sikre at meldingen er svært sanntids, og at sanntidsmeldingen ikke er lavere enn push-meldingen.
Minst én gang betyr at hver melding må leveres én gang.
RocketMQ Consumer henter først meldingen til lokalområdet, og returnerer deretter acken til serveren etter at forbruket er fullført.
Nøyaktig bare én gang- Sendingsfasen for melding tillater ikke sending av duplikatmeldinger.
- I Konsumer melding-fasen er det ikke tillatt å konsumere dupliserte meldinger.
Først når de to ovennevnte betingelsene er oppfylt, kan meldingen regnes som «Nøyaktig bare én gang», og for å oppnå de to ovennevnte punktene vil det uunngåelig genereres enorme overhead i det distribuerte systemmiljøet. Derfor garanterer ikke RocketMQ denne funksjonen for å oppnå høy ytelse, og krever deduplisering i virksomheten, noe som betyr at forbrukermeldinger må være idempotente. Selv om RocketMQ ikke kan garantere ikke-duplisering strengt, forekommer det under normale omstendigheter sjelden gjentatt sending og forbruk, kun nettverksavvik, forbrukerstart og -stopp, og andre unormale situasjoner som meldingsduplisering.
Den grunnleggende årsaken til dette problemet er at det er usikkerhet i nettverkssamtaler, det vil si den tredje tilstanden av verken suksess eller fiasko, så problemet med meldingsrepetisjon oppstår.
Hva bør jeg gjøre hvis Broker's Buffer er full? Meglerens buffer refererer vanligvis til minnebufferstørrelsen på en kø i megleren, som vanligvis er begrenset i størrelse, hva om bufferen er full?
Slik håndteres det i CORBA-varslingsspesifikasjonen:
- RejectNewEvents avviser den nye meldingen og returnerer feilkoden RejectNewEvents til produsenten.
- Kast eksisterende meldinger i henhold til en spesifikk policy
- AnyOrder – Enhver hendelse kan forkastes ved overflow. Dette er standardinnstillingen for denne egenskapen.
- FifoOrder – Den første hendelsen som mottas er den første som kastes.
- LifoOrder – Den siste hendelsen som mottas vil være den første som kastes.
- PriorityOrder – Hendelser bør kastes i prioritert rekkefølge, slik at lavere prioriterte hendelser kastes før hendelser med høyere prioritet.
- DeadlineOrder – Hendelser bør først kastes i rekkefølgen etter korteste utløpsfrist.
RocketMQ har ikke konseptet minnebuffer, og køene i RocketMQ er persistente disker, og dataene slettes jevnlig.
For løsningen på dette problemet har RocketMQ en svært betydelig forskjell fra andre MQ-er, RocketMQs minnebuffer er abstrahert til en kø med uendelig lengde, uansett hvor mye data som kommer inn, kan den installeres, denne uendeligheten er premiss, megleren vil jevnlig slette utløpte data, for eksempel lagrer megleren bare meldinger i 3 dager, og selv om lengden på denne bufferen er uendelig, vil dataene fra 3 dager siden bli slettet fra slutten av køen.
Retrospektiv konsum refererer til budskapet som forbrukeren har tatt til seg, og budskapet må konsumeres på nytt på grunn av etterspørsel fra virksomheten. For eksempel, på grunn av feil i forbrukersystemet, må dataene fra for 1 time siden konsumeres på nytt etter gjenoppretting, deretter bør megleren gi en mekanisme for å reversere forbruksfremdriften i henhold til tidsdimensjonen.
RocketMQ støtter retrospektivt forbruk basert på tid, med en tidsdimensjon nøyaktig på millisekunder, som kan spores fremover eller bakover.
Hovedfunksjonen til message stacking message middleware er asynkron frakobling, og en annen viktig funksjon er å blokkere dataflom-toppen i front-end og sikre stabiliteten til back-end-systemet, noe som krever at meldingsmiddleware har en viss message stacking-evne, og message heap integrerer følgende to situasjoner:
- Meldinger stables opp i minnebuffere, og når de overskrider minnebufferen, kan meldinger slippes i henhold til en bestemt dropppolicy, som beskrevet i CORBA Notification-spesifikasjonen. Den er egnet for tjenester som tåler å kaste meldinger, i dette tilfellet ligger akkumuleringskapasiteten for meldinger hovedsakelig i størrelsen på minnebufferen, og ytelsesforringelsen vil ikke være for stor etter at meldingen er stablet, fordi datamengden i minnet har begrenset innvirkning på tilgangsmuligheten som gis til omverdenen.
- Meldinger stables opp i persistente lagringssystemer som DB, KV-lagring, filpostskjema. Når meldinger ikke kan treffes i minnecachen, er det uunngåelig å få tilgang til disken, noe som vil generere en stor mengde lese-IO, og gjennomstrømningen til lese-IO bestemmer direkte tilgangsevnen til meldingene etter at de er stablet opp.
Det er fire hovedpunkter for å evaluere evnen til å samle meldinger:
- Hvor mange meldinger kan stables opp, hvor mange bytes? Det vil si heap-kapasiteten til meldingen.
- Etter at en melding er stablet opp, påvirkes gjennomstrømningen av meldingen av stablingen?
- Vil forbrukernes normale forbruk bli påvirket etter at meldingene hoper seg opp?
- Etter at meldingene er samlet opp, hva er gjennomstrømningen når man får tilgang til meldinger som er samlet på disken?
Distribuerte transaksjoner Flere kjente distribuerte transaksjonsspesifikasjoner, som XA, JTA, osv. Blant dem støttes XA-spesifikasjonen bredt av store databaseleverandører, som Oracle, Mysql, osv. Blant dem er XAs TM-implementeringsleder som Oracle Tuxedo mye brukt innen finans, telekommunikasjon og andre felt.
Distribuerte transaksjoner involverer to-trinns commit-problemer, og når det gjelder datalagring, må KV-lagring støttes, fordi det andre trinnet i commit rollback må endre meldingsstatusen, noe som må innebære handlingen å finne meldingen i henhold til nøkkelen. RocketMQ omgår problemet med å finne meldingen i henhold til nøkkelen i andre trinn, ved å bruke første trinn til å sende den forberedte meldingen, hente offsettet til meldingen, og andre trinn til å få tilgang til meldingen gjennom offset og endre tilstanden, offsetet er adressen til dataene.
RocketMQs transaksjonsimplementeringsmetode gjøres ikke via KV-lagring, men gjennom offset-metoden, som har en betydelig svakhet, nemlig at endring av data via offset vil føre til for mange skitne sider i systemet, noe som krever spesiell oppmerksomhet.
Planlagte meldinger Planlagte meldinger betyr at meldinger ikke kan konsumeres av forbrukere umiddelbart etter at de er sendt til megleren, og kun kan konsumeres på et bestemt tidspunkt eller etter å ha ventet på et bestemt tidspunkt.
Hvis du vil støtte vilkårlig tidsnøyaktighet på meglernivå, må du gjøre meldingssortering, og hvis persistens er involvert, vil meldingssortering uunngåelig medføre store ytelsesoverhead.
RocketMQ støtter tidsmeldinger, men støtter ikke vilkårlig tidsnøyaktighet, og støtter spesifikke nivåer, som timing 5s, 10s, 1m, osv.
Meldingsforsøk på nytt Etter at forbrukeren ikke klarer å konsumere meldingen, gi en retry-mekanisme for å få meldingen til å konsumeres igjen. Forbrukermeldingsfeil kan vanligvis vurderes i følgende situasjoner:
- På grunn av selve meldingen, som deserialiseringsfeil, kan ikke meldingsdataene behandles (for eksempel opplading av telefonregningen, mobilnummeret til den nåværende meldingen er logget ut, kan ikke lades opp), osv. Denne feilen krever vanligvis at man hopper over denne meldingen og konsumerer andre meldinger, og denne mislykkede meldingen er 99 % mislykket selv om forbruket prøves på nytt umiddelbart, så det er best å tilby en tidsbestemt retry-mekanisme, det vil si å prøve igjen etter 10 sekunder.
- Fordi de avhengige nedstrøms applikasjonstjenestene ikke er tilgjengelige, for eksempel at DB-tilkoblingen ikke er tilgjengelig, det eksterne systemnettverket er utilgjengelig, osv. Når denne feilen oppstår, selv om den nåværende mislykkede meldingen hoppes over, vil også andre meldinger bli konsumert. I dette tilfellet anbefales det å legge inn 30 sekunders søvn og konsumere neste melding, noe som kan redusere presset på megleren for å prøve meldingen på nytt.
RocketMQ OversiktLa oss finne ut om RocketMQ løser problemene som meldingsmellomvaren nevnt ovenfor møter.
Hva er RocketMQ?
Figuren ovenfor er en typisk modell for meldingsmellomvare som sender og mottar meldinger, RocketMQ er også designet på denne måten, kort sagt har RocketMQ følgende egenskaper:
- Det er en kømodell-meldingsmellomvare med høy ytelse, høy pålitelighet, høy sanntids- og distribuerte egenskaper.
- Produsent, forbruker og kø kan alle distribueres.
- Produsenten sender meldinger til noen køer i sin tur, køsamlingen kalles Topic, Consumer Hvis broadcast forbruk, konsumerer én konsumentinstans alle køer som tilsvarer dette temaet, og hvis det er klusgekonsum, bruker flere konsumentinstanser køsamlingen som tilsvarer dette temaet jevnt.
- Streng meldingsrekkefølge kan garanteres
- Tilbyr rike meldingstrekkmoduser
- Effektive horisontale abonnentskaleringsmuligheter
- Sanntids meldingsabonnementsmekanisme
- Hundrevis av millioner av meldinger akkumulerer kapasitet
- Mindre avhengighet
RocketMQs fysiske utplasseringsstruktur
Som vist i figuren ovenfor, har utplasseringsstrukturen til RocketMQ følgende egenskaper:
- Name Server er en praktisk talt tilstandsløs node som kan distribueres i klynger uten noen informasjonssynkronisering mellom noder.
- Utplasseringen av Broker er relativt kompleks, Broker er delt inn i Master og Slave, en Master kan tilsvare flere Slaver, men en Slave kan bare tilsvare én Master, korrespondansen mellom Master og Slave defineres ved å spesifisere samme BrokerName, forskjellig BrokerId, BrokerId er 0 for Master, og ikke-0 betyr Slave. Masters kan også brukes i flere grupper. Hver megler etablerer en lang forbindelse med alle noder i navneserverklyngen og registrerer emneinformasjon til alle navneservere med jevne mellomrom.
- Produsenten etablerer en lang forbindelse med en av nodene i Name Server-klyngen (tilfeldig valgt), henter periodisk emnerutingsinformasjon fra Name Server, etablerer en lang forbindelse til masteren som leverer topic-tjenesten, og sender hjerteslag til masteren med jevne mellomrom. Producer er fullstendig tilstandsløs og kan distribueres i klynger.
- Forbrukeren etablerer en lang forbindelse med en av nodene i navneserverklyngen (tilfeldig valgt), henter jevnlig emnerutingsinformasjon fra navneserveren, etablerer en lang forbindelse til Master og Slave som leverer emnetjenesten, og sender hjerteslag til Master og Slave med jevne mellomrom. Forbrukere kan abonnere på meldinger fra både Master og Slave, og abonnementsreglene bestemmes av Broker-konfigurasjonen.
RocketMQ logisk utplasseringsstruktur
Som vist i figuren ovenfor, har den logiske distribusjonsstrukturen til RocketMQ to kjennetegn: Produsent og Forbruker.
Brukt til å representere en meldingsapplikasjon, inneholder en Producer Group flere Producer-instanser, som kan være flere maskiner, flere prosesser i en maskin, eller flere Producer-objekter i en prosess. En Producer Group kan sende flere Topic-meldinger, og Producer Group fungerer som følger:
- Identifiser en type produsent
- Du kan spørre om det finnes flere Producer-instanser i denne meldingsapplikasjonen via O&M-verktøyet
- Når man sender en distribuert transaksjonsmelding, hvis produsenten går ned uventet, vil megleren aktivt kalle tilbake hvilken som helst maskin i produsentgruppen for å bekrefte transaksjonsstatusen.
Brukt til å representere en forbrukermeldingsapplikasjon, inneholder en forbrukergruppe flere forbrukerinstanser, som kan være flere maskiner, flere prosesser eller flere forbrukerobjekter i en prosess. Flere forbrukere i en forbrukergruppe konsumerer meldinger jevnt fordelt, og hvis de settes til kringkasting, bruker hver instans under denne forbrukergruppen hele mengden data.
RocketMQ datalagringsstruktur
Som vist i figuren ovenfor, benytter RocketMQ en lagringsmetode som skiller data fra indekser. Reduser effektivt tap av filressurser, IO-ressurser og minneressurser. Selv med massiv data som Alibaba kan scenarioer med høy samtidighet effektivt redusere ende-til-ende-latens og ha sterke horisontale skaleringsmuligheter.
|
Publisert på 28.07.2017 20:26:52
|
|
|
|
Publisert på 29.07.2017 08:09:37