Šiame straipsnyje pirmiausia paaiškinama, kokias problemas paprastai reikia išspręsti pranešimų tarpinei programinei įrangai, su kokiais sunkumais susidursite sprendžiant šias problemas, ar "Apache RocketMQ" gali būti išspręsta kaip didelio našumo, didelio pralaidumo paskirstyta pranešimų tarpinė programinė įranga "Alibaba" atvirojo kodo ir kaip šios problemos apibrėžiamos specifikacijoje. Šiame straipsnyje bus pristatytas "RocketMQ" architektūros dizainas, kad skaitytojai greitai suprastų "RocketMQ".
1. Kokias problemas turi išspręsti pranešimų tarpinė programinė įranga? Publikuoti / Prenumeruoti yra pagrindinė pranešimų tarpinės programinės įrangos funkcija ir taip pat yra susijusi su tradiciniu RPC ryšiu. Čia nesigilinsiu į detales.
Pranešimo prioriteto specifikacijoje aprašytas prioritetas reiškia pranešimų eilę, kiekvienas pranešimas turi skirtingą prioritetą, paprastai apibūdinamas sveikaisiais skaičiais, pirmiausia pristatomas aukšto prioriteto pranešimas, jei pranešimas yra visiškai atminties eilėje, tada jį galima rūšiuoti pagal prioritetą prieš pristatymą, kad pirmiausia būtų pristatytas aukštas prioritetas.
Kadangi visi "RocketMQ" pranešimai yra nuolatiniai, jei jie bus rūšiuojami pagal prioritetą, pridėtinės išlaidos bus labai didelės, todėl "RocketMQ" specialiai nepalaiko pranešimų prioriteto, tačiau gali įdiegti panašias funkcijas sprendime, tai yra, sukonfigūruoti eilę su dideliu prioritetu ir eilę su įprastu prioritetu ir siųsti skirtingus prioritetus į skirtingas eiles.
Prioritetinius klausimus juos galima apibendrinti į 2 kategorijas:
- Kol prioritetas pasiekiamas, jis nėra prioritetas siaurąja prasme, o prioritetas paprastai skirstomas į aukštą, vidutinį, žemą ar dar kelis lygius. Kiekvienas prioritetas gali būti pavaizduotas skirtinga tema, o siųsdami pranešimą nurodykite skirtingas temas, kurios gali išspręsti daugumą prioritetinių problemų, tačiau pakenkti verslo prioritetų tikslumui.
- Griežtas prioritetas, prioritetas išreiškiamas sveikuoju skaičiumi, pvz., 0 ~ 65535, tokia prioritetinė problema paprastai nėra tinkama spręsti skirtingomis temomis. Jei norite, kad MQ išspręstų šią problemą, tai turės labai didelę įtaką MQ veikimui. Štai dalykas, kad įsitikintumėte, jog verslui tikrai reikia šio griežto prioritetų nustatymo, o jei prioritetai bus suspausti į kelis, kokį poveikį tai turės verslui?
Pranešimų tvarka nurodo pranešimo tipą, kuris gali būti vartojamas tokia tvarka, kokia jis išsiųstas. Pavyzdžiui, užsakymas generuoja 3 pranešimus, būtent užsakymo sukūrimą, užsakymo apmokėjimą ir užsakymo užbaigimą. Vartojant prasminga vartoti tokia tvarka. Tačiau tuo pačiu metu užsakymai gali būti vartojami lygiagrečiai.
"RocketMQ" gali griežtai užtikrinti, kad pranešimai būtų tvarkingi.
Pranešimų filtrasBroker Pranešimų filtravimas
Brokeryje filtravimas pagal vartotojo reikalavimus turi pranašumą, nes sumažina nereikalingų pranešimų perdavimą vartotojui.
Trūkumas yra tas, kad tai padidina brokerio naštą ir yra gana sudėtinga įgyvendinti.
1. "Taobao Notify" palaiko įvairius filtravimo metodus, įskaitant tiesioginį filtravimą pagal pranešimo tipą ir lanksčią sintaksės išraiškos filtravimą, kurie gali patenkinti beveik pačius reikliausius filtravimo poreikius.
2. "Taobao RocketMQ" palaiko filtravimą pagal paprastą pranešimo žymą, taip pat pranešimo antraštę ir turinį.
3. Lankstus sintaksės išraiškos filtravimas taip pat palaikomas CORBA pranešimo specifikacijoje.
Vartotojo pranešimų filtravimas
Šį filtravimą programa gali visiškai pritaikyti, tačiau trūkumas yra tas, kad vartotojui siunčiama daug nenaudingų pranešimų.
Yra keli įprasti patvarumo metodai, naudojami pranešimų atkaklumui:
- Išlaikykite duomenų bazę, pvz., Mysql.
- Išlaikykite KV saugyklą, pvz., levelDB, Berkeley DB ir kitas KV saugojimo sistemas.
- Atkaklumas failų įrašų pavidalu, pvz., "Kafka", "RocketMQ"
- Sukurkite nuolatinį atminties duomenų vaizdą, pvz., "beanstalkd", "VisiNotify"
- (1), (2) ir (3) visi trys patvarumo metodai turi galimybę išplėsti atminties eilės buferį, ir (4) yra tik atminties vaizdas, kuris vis dar gali atkurti duomenis iš ankstesnės atminties po to, kai brokeris pakabina ir paleidžia iš naujo.
JMS ir CORBA pranešimų specifikacijose nėra aiškiai nurodyta, kaip išlikti, tačiau patvarumo dalies veikimas tiesiogiai lemia visos pranešimo tarpinės programinės įrangos veikimą.
"RocketMQ" visiškai išnaudoja "Linux" failų sistemos atminties talpyklą, kad pagerintų našumą.
Yra keletas situacijų, kai pranešimų patikimumas turi įtakos pranešimo patikimumui:
- Brokeris užsidaro įprastai
- Brokerio avarija
- OS gedimas
- Mašina praranda maitinimą, tačiau maitinimą galima nedelsiant atkurti.
- Aparatas neįsijungia (gali būti pažeisti pagrindiniai įrenginiai, pvz., procesorius, pagrindinė plokštė, atmintis ir kt.)
- Disko įrenginio pažeidimas.
(1), (2), (3) ir (4) yra situacijos, kai aparatinės įrangos išteklius galima nedelsiant atkurti, o "RocketMQ" gali užtikrinti, kad pranešimai nebūtų prarasti arba prarastas nedidelis duomenų kiekis (priklausomai nuo to, ar mirksėjimo metodas yra sinchroninis, ar asinchroninis).
(5) (6) Tai yra vienas gedimo taškas ir jo negalima atkurti, kai jis įvyksta, visi pranešimai apie šį vieną tašką prarandami. Abiem atvejais "RocketMQ" užtikrina, kad 99% pranešimų nebūtų prarasti asinchroninio replikavimo metu, tačiau vis tiek yra labai mažai pranešimų, kurie gali būti prarasti. Sinchroninė dvigubo rašymo technologija gali visiškai išvengti pavienių taškų, kurie neišvengiamai turės įtakos našumui, todėl tinka situacijoms, kuriose yra itin aukšti pranešimų patikimumo reikalavimai, pvz., su pinigais susijusioms programoms.
"RocketMQ" palaiko sinchroninį dvigubą rašymą nuo 3.0 versijos.
Mažos delsos pranešimai gali pasiekti vartotoją iškart po to, kai pranešimas pasiekia brokerį, nesikaupiant pranešimams.
"RocketMQ" naudoja ilgą apklausos traukimo metodą, kad užtikrintų, jog pranešimas yra labai realiuoju laiku, o pranešimas realiuoju laiku nėra mažesnis nei stūmimo.
Bent kartą reiškia, kad kiekvienas pranešimas turi būti pristatytas vieną kartą.
"RocketMQ Consumer" pirmiausia ištraukia pranešimą į vietinę sritį, o pasibaigus vartojimui grąžina ack į serverį.
Tiksliai tik vieną kartą- Pranešimo siuntimo etapas neleidžia siųsti pasikartojančių pranešimų.
- Etape Vartoti pranešimą neleidžiama vartoti pasikartojančių pranešimų.
Tik įvykdžius dvi aukščiau nurodytas sąlygas, pranešimas gali būti laikomas "tiksliai tik vieną kartą", o norint pasiekti aukščiau nurodytus du taškus, paskirstytoje sistemos aplinkoje neišvengiamai bus sukurtos didžiulės pridėtinės išlaidos. Todėl, norint pasiekti aukštą našumą, "RocketMQ" negarantuoja šios funkcijos ir reikalauja dublikatų šalinimo versle, o tai reiškia, kad vartotojų pranešimai turi būti idempotentiniai. Nors "RocketMQ" negali griežtai garantuoti nedubliavimo, įprastomis aplinkybėmis retai pasikartoja siuntimas ir vartojimas, tik tinklo anomalijos, vartotojo paleidimas ir sustabdymas bei kitos neįprastos situacijos, tokios kaip pranešimų dubliavimas.
Esminė šios problemos priežastis yra ta, kad tinklo skambučiuose yra neapibrėžtumas, tai yra trečioji nei sėkmės, nei nesėkmės būsena, todėl kyla pranešimų kartojimo problema.
Ką daryti, jei brokerio buferis pilnas? Brokerio buferis paprastai reiškia brokerio eilės atminties buferio dydį, kurio dydis paprastai yra ribotas, ką daryti, jei buferis pilnas?
Štai kaip tai tvarkoma CORBA pranešimo specifikacijoje:
- RejectNewEvents atmeta naują pranešimą ir grąžina RejectNewEvents klaidos kodą gamintojui.
- Esamų pranešimų atmetimas pagal konkrečią strategiją
- AnyOrder – bet koks įvykis gali būti atmestas perpildžius. Tai numatytasis šios ypatybės parametras.
- FifoOrder – pirmasis gautas įvykis bus pirmasis atmestas.
- LifoOrder - Paskutinis gautas įvykis bus pirmasis atmestas.
- PriorityOrder – įvykiai turi būti atmesti prioriteto tvarka, kad žemesnio prioriteto įvykiai būtų atmesti prieš aukštesnio prioriteto įvykius.
- DeadlineOrder – įvykiai pirmiausia turi būti atmesti trumpiausio galiojimo termino tvarka.
"RocketMQ" neturi atminties buferio sąvokos, o "RocketMQ" eilės yra nuolatiniai diskai, o duomenys reguliariai valomi.
Šios problemos sprendimui "RocketMQ" turi labai reikšmingą skirtumą nuo kitų MQ, "RocketMQ" atminties buferis yra abstrahuotas į begalinio ilgio eilę, nesvarbu, kiek duomenų gaunama, jį galima įdiegti, ši begalybė yra prielaida, brokeris reguliariai ištrins pasibaigusius duomenis, pavyzdžiui, brokeris išsaugo tik 3 dienas pranešimų, tada, nors šio buferio ilgis yra begalinis, tačiau prieš 3 dienas duomenys bus ištrinti iš eilės pabaigos.
Retrospektyvus vartojimas reiškia pranešimą, kad vartotojas sėkmingai suvartojo, o pranešimą reikia pakartotinai vartoti dėl verslo paklausos. Pavyzdžiui, dėl vartotojų sistemos gedimo prieš 1 valandą duomenis reikia pakartotinai sunaudoti po atkūrimo, tada brokeris turėtų pateikti mechanizmą, kaip grąžinti vartojimo eigą pagal laiko dimensiją.
"RocketMQ" palaiko retrospektyvų suvartojimą pagal laiką, kurio laiko matmuo yra tiksli milisekundėmis, kurią galima atsukti pirmyn arba atgal.
Pagrindinė pranešimų krovimo tarpinės programinės įrangos funkcija yra asinchroninis atsiejimas, o kita svarbi funkcija yra blokuoti priekinės dalies duomenų potvynio piką ir užtikrinti galinės sistemos stabilumą, o tai reikalauja, kad pranešimų tarpinė programinė įranga turėtų tam tikrą pranešimų krovimo galimybę, o pranešimų krūva integruoja šias dvi situacijas:
- Pranešimai kaupiami atminties buferiuose, o kai jie viršija atminties buferį, pranešimai gali būti numesti pagal tam tikrą kritimo politiką, kaip aprašyta CORBA pranešimų specifikacijoje. Jis tinka paslaugoms, kurios gali toleruoti pranešimų atmetimą, šiuo atveju pranešimų kaupimo talpa daugiausia priklauso nuo atminties buferio dydžio, o sukrautas pranešimas nebus per didelis, nes duomenų kiekis atmintyje turi ribotą įtaką prieigos prie išorinio pasaulio galimybėms.
- Pranešimai kaupiami nuolatinėse saugojimo sistemose, tokiose kaip DB, KV saugykla, failų įrašų forma. Kai pranešimų negalima pataikyti į atminties talpyklą, neišvengiama prieiga prie disko, kuris sugeneruos didelį kiekį nuskaityto IO, o skaityto IO pralaidumas tiesiogiai lemia pranešimų prieigą po to, kai jie yra sukrauti.
Yra keturi pagrindiniai dalykai, norint įvertinti pranešimų kaupimo galimybes:
- Kiek pranešimų galima sukrauti, kiek baitų? Tai yra, pranešimo krūvos talpa.
- Ar sukaupus pranešimą krūva turi įtakos pranešimo pralaidumui?
- Ar bus paveiktas įprastas vartotojų vartojimas po to, kai žinutė kaupiasi?
- Po to, kai pranešimai yra sukrauti, koks yra pralaidumas, kai prieiga prie pranešimų sukrauti diske?
Paskirstytos operacijos Kelios žinomos paskirstytų operacijų specifikacijos, tokios kaip XA, JTA ir kt. Tarp jų XA specifikaciją plačiai palaiko pagrindiniai duomenų bazių pardavėjai, tokie kaip Oracle, MySQL ir kt. Tarp jų XA TM diegimo lyderis, toks kaip "Oracle Tuxedo", yra plačiai naudojamas finansų, telekomunikacijų ir kitose srityse.
Paskirstytos operacijos susijusios su dviejų pakopų įsipareigojimų problemomis, o kalbant apie duomenų saugojimą, KV saugykla turi būti palaikoma, nes antrasis įsipareigojimo atšaukimo etapas turi pakeisti pranešimo būseną, kuri turi apimti pranešimo paiešką pagal raktą. "RocketMQ" apeina pranešimo paieškos pagal raktą problemą antrajame etape, naudojant pirmąjį etapą paruoštam pranešimui siųsti, gauti pranešimo poslinkį, o antrąjį etapą pasiekti pranešimą per poslinkį ir pakeisti būseną, poslinkis yra duomenų adresas.
"RocketMQ" operacijų įgyvendinimo metodas atliekamas ne per KV saugyklą, o per ofsetinį metodą, kuris turi reikšmingą trūkumą, tai yra, pakeitus duomenis per poslinkį, sistemoje atsiras per daug nešvarių puslapių, o tai reikalauja ypatingo dėmesio.
Suplanuoti pranešimai Suplanuoti pranešimai reiškia, kad vartotojai negali vartoti pranešimų iš karto po to, kai jie išsiunčiami brokeriui, ir gali būti vartojami tik tam tikru laiku arba laukiant tam tikro laiko.
Jei norite palaikyti savavališką laiko tikslumą, brokerio lygiu turite atlikti pranešimų rūšiavimą, o jei tai susiję su atkaklumu, pranešimų rūšiavimas neišvengiamai patirs didžiules našumo sąnaudas.
"RocketMQ" palaiko laiko pranešimus, bet nepalaiko savavališko laiko tikslumo ir palaiko konkrečius lygius, tokius kaip 5s, 10s, 1m ir kt.
Pakartoti pranešimą Kai vartotojui nepavyksta suvartoti pranešimo, pateikite pakartotinio bandymo mechanizmą, kad pranešimas vėl sunaudotų. Vartotojų vartojimo pranešimų gedimai paprastai gali būti laikomi šiais atvejais:
- Dėl paties pranešimo priežasties, pvz., deserializacijos gedimo, patys pranešimo duomenys negali būti apdorojami (pvz., telefono sąskaitos papildymas, dabartinio pranešimo mobiliojo telefono numeris yra atjungtas, jo negalima įkrauti) ir kt. Dėl šios klaidos paprastai reikia praleisti šį pranešimą ir vartoti kitus pranešimus, o šis nepavykęs pranešimas yra 99% nesėkmingas, net jei nedelsiant bandoma pakartoti, todėl geriausia pateikti laiko pakartotinio bandymo mechanizmą, tai yra, pakartoti po 10 sekundžių.
- Kadangi priklausomos tolesnės taikomosios programos paslaugos nepasiekiamos, pvz., DB ryšys nepasiekiamas, išorinis sistemos tinklas nepasiekiamas ir pan. Susidūrus su šia klaida, net jei dabartinis nepavykęs pranešimas bus praleistas, bus sunaudoti ir kiti pranešimai. Tokiu atveju rekomenduojama taikyti 30 sekundžių miego režimą ir suvartoti kitą pranešimą, kuris gali sumažinti spaudimą brokeriui pakartoti pranešimą.
"RocketMQ" apžvalgaIšsiaiškinkime, ar "RocketMQ" išsprendžia problemas, su kuriomis susiduria aukščiau minėta pranešimų tarpinė programinė įranga.
Kas yra "RocketMQ"?
Aukščiau pateiktas paveikslėlis yra tipiškas pranešimų tarpinės programinės įrangos siuntimo ir gavimo modelis, "RocketMQ" taip pat sukurtas tokiu būdu, trumpai tariant, "RocketMQ" turi šias savybes:
- Tai eilės modelio pranešimų tarpinė programinė įranga, pasižyminti dideliu našumu, dideliu patikimumu, dideliu realiuoju laiku ir paskirstytomis savybėmis.
- Gamintojas, vartotojas ir eilė gali būti paskirstyti.
- Gamintojas siunčia pranešimus į kai kurias eiles paeiliui, eilių rinkinys vadinamas Tema, Vartotojas Jei transliacijos suvartojimas, vienas vartotojo egzempliorius sunaudoja visas šią temą atitinkančias eiles, o jei klasterio suvartojimas, keli vartotojų egzemplioriai tolygiai sunaudoja šią temą atitinkantį eilių rinkinį.
- Galima garantuoti griežtą pranešimų tvarką
- Pateikia raiškius pranešimų traukimo režimus
- Efektyvios horizontalaus abonento mastelio keitimo galimybės
- Realaus laiko pranešimų prenumeratos mechanizmas
- Šimtai milijonų pranešimų kaupimo pajėgumas
- Mažesnė priklausomybė
"RocketMQ" fizinio dislokavimo struktūra
Kaip parodyta aukščiau esančiame paveikslėlyje, "RocketMQ" diegimo struktūra turi šias charakteristikas:
- Vardų serveris yra praktiškai be būsenos mazgas, kurį galima įdiegti klasteriuose be jokio informacijos sinchronizavimo tarp mazgų.
- Brokerio diegimas yra gana sudėtingas, Brokeris yra padalintas į Master ir Slave, Master gali atitikti kelis Slaves, bet Slave gali atitikti tik vieną Master, atitikimas tarp Master ir Slave apibrėžiamas nurodant tą patį BrokerName, skirtingą BrokerId, BrokerId yra 0 Master, o ne 0 reiškia Slave. Meistrai taip pat gali būti naudojami keliuose. Kiekvienas brokeris užmezga ilgą ryšį su visais vardų serverio klasterio mazgais ir reguliariai registruoja teminę informaciją visuose vardų serveriuose.
- Prodiuseris užmezga ilgą ryšį su vienu iš vardų serverio klasterio mazgų (atsitiktinai parinktas), periodiškai nuskaito temų nukreipimo informaciją iš vardų serverio, užmezga ilgą ryšį su pagrindiniu asmeniu, kuris teikia temų paslaugą, ir reguliariai siunčia širdies plakimus meistrui. Gamintojas yra visiškai be būsenos ir gali būti diegiamas klasteriuose.
- Vartotojas užmezga ilgą ryšį su vienu iš vardų serverio klasterio mazgų (atsitiktinai parinktas), reguliariai gauna temų nukreipimo informaciją iš vardų serverio ir užmezga ilgą ryšį su pagrindiniu ir pavaldiniu, kurie teikia teminę paslaugą, ir reguliariai siunčia širdies plakimus pagrindiniam ir vergui. Vartotojai gali užsiprenumeruoti pranešimus iš "Master" ir "Slave", o prenumeratos taisykles nustato brokerio konfigūracija.
"RocketMQ" loginė diegimo struktūra
Kaip parodyta aukščiau esančiame paveikslėlyje, loginė "RocketMQ" diegimo struktūra turi dvi charakteristikas: gamintojas ir vartotojas.
Gamintojų grupėje, naudojamoje pranešimų programai, yra keli gamintojo egzemplioriai, kurie gali būti kelios mašinos, keli mašinos procesai arba keli gamintojo proceso objektai. Gamintojų grupė gali siųsti kelis teminius pranešimus, o gamintojų grupė veikia taip:
- Nustatykite gamintojo tipą
- Galite užklausti, ar šioje pranešimų programoje yra keli gamintojo egzemplioriai naudodami O&M įrankį
- Siunčiant paskirstytą sandorio pranešimą, jei gamintojas netikėtai sugenda, brokeris aktyviai perskambins bet kuriai gamintojų grupės mašinai, kad patvirtintų sandorio būseną.
Vartotojų grupėje, naudojamoje vartotojų pranešimų programai, yra keli vartotojų egzemplioriai, kurie gali būti keli įrenginiai, keli procesai arba keli proceso vartotojų objektai. Keli vartotojų grupės vartotojai pranešimus vartoja tolygiai, o jei nustatyta transliuoti, kiekvienas šios vartotojų grupės egzempliorius sunaudoja visą duomenų kiekį.
"RocketMQ" duomenų saugojimo struktūra
Kaip parodyta aukščiau esančiame paveikslėlyje, "RocketMQ" taiko saugojimo metodą, kuris atskiria duomenis nuo indeksų. Efektyviai sumažinkite failų išteklių, IO išteklių ir atminties išteklių praradimą. Net ir naudojant didžiulius duomenis, tokius kaip "Alibaba", didelio sutapimo scenarijai gali veiksmingai sumažinti delsą nuo galo iki galo ir turėti stiprias horizontalaus mastelio galimybes.
|
Paskelbta 2017-07-28 20:26:52
|
|
|
|
Paskelbta 2017-07-29 08:09:37