See artikkel viib esmalt selleni, milliseid probleeme sõnumivahendustarkvara tavaliselt lahendama peab, milliseid raskusi nende lahendamisel ees ootab, kas Apache RocketMQ-d saab lahendada kui Alibaba poolt avatud lähtekoodiga kõrge jõudlusega ja suure läbilaskevõimega hajutatud sõnumivahendustarkvara ning kuidas need probleemid on spetsifikatsioonis määratletud. See artikkel tutvustab seejärel RocketMQ arhitektuuridisaini, et anda lugejatele kiire ülevaade RocketMQ-st.
1. Milliseid probleeme peab sõnumite vahendustarkvara lahendama? Avalda/Telli on sõnumite vahendustarkvara kõige põhilisem funktsioon ja võrreldav ka traditsioonilise RPC kommunikatsiooniga. Ma ei hakka siin üksikasjadesse laskuma.
Sõnumi prioriteedi spetsifikatsioonis kirjeldatud prioriteet viitab sõnumijärjekorrale, igal sõnumil on erinev prioriteet, mida tavaliselt kirjeldatakse täisarvudega, kõrge prioriteediga sõnum toimetatakse esimesena, kui sõnum on täielikult mälujärjekorras, saab selle sorteerida prioriteedi järgi enne kohaletoimetamist, nii et kõrge prioriteediga jõudmine toimetatakse esimesena.
Kuna kõik RocketMQ sõnumid on püsivad, siis kui need sorteeritakse prioriteedi järgi, on koormus väga suur, seega RocketMQ ei toeta otseselt sõnumi prioriteeti, kuid saab rakendada sarnaseid funktsioone lahendusena, st konfigureerida kõrge prioriteediga järjekorra ja normaalse prioriteediga järjekorra ning saata erinevad prioriteedid erinevatele järjekordadele.
Prioriteetsete küsimuste puhul saab neid kokku võtta kahte kategooriasse:
- Kui prioriteet on saavutatud, ei ole see rangelt prioriteet ning prioriteet jaguneb tavaliselt kõrgeks, keskmiseks, madalaks või mitmeks tasemeks. Iga prioriteet võib olla esindatud erineva teemaga ning sõnumi saatmisel määratakse erinevad teemad, mis esindavad prioriteeti, mis võib lahendada enamiku prioriteetiprobleeme, kuid kahjustada äriliste prioriteetide täpsust.
- Range prioriteediga on prioriteet väljendatud täisarvuna, näiteks 0 ~ 65535, sellist prioriteediprobleemi ei sobi tavaliselt lahendamiseks erinevate teemadega. Kui soovid, et MQ selle probleemi lahendaks, avaldab see MQ jõudlusele väga suurt mõju. Siin on üks punkt, et veenduda, et ettevõte vajab tõesti ranget prioriteetide seadmist, ja kui prioriteedid on kokku surutud mõneks, kui palju mõju see ettevõttele avaldab?
Sõnumi järjekord viitab sõnumitüübile, mida saab tarbida selles järjekorras, nagu see saadetakse. Näiteks tellimus genereerib 3 sõnumit: tellimuse loomine, tellimuse tasumine ja tellimuse lõpetamine. Tarbides on selle järjekorras tarbimine tähenduslik. Kuid samal ajal saab tellimusi tarbida paralleelselt.
RocketMQ saab rangelt tagada, et sõnumid on korrapärased.
Message FilterBroker Sõnumifiltreerimine
Maakleris on tarbija vajadustele vastavalt filtreerimisel eeliseks see, et vähendada tarbetute sõnumite edastamist tarbijale.
Puuduseks on see, et see suurendab maakleri koormust ja on suhteliselt keeruline rakendada.
1. Taobao Notify toetab mitmesuguseid filtreerimismeetodeid, sealhulgas otsefiltreerimist sõnumitüübi järgi ja paindlikku süntaksi väljendite filtreerimist, mis suudab rahuldada peaaegu kõige nõudlikumaid filtreerimisvajadusi.
2. Taobao RocketMQ toetab filtreerimist lihtsa sõnumimärgi, sõnumipäise ja keha abil.
3. Paindlik süntaksi väljendite filtreerimine on samuti toetatud CORBA teavituse spetsifikatsioonis.
Tarbijapoolne sõnumite filtreerimine
Seda filtreerimist saab rakendus täielikult kohandada, kuid miinuseks on see, et tarbijale saadetakse palju mõttetuid sõnumeid.
Sõnumi püsivuse puhul kasutatakse mitmeid levinud püsivuse meetodeid:
- Püsi andmebaasis, näiteks MySQL-is.
- Püsi KV-salvestusse, näiteks levelDB, Berkeley DB ja teised KV salvestussüsteemid.
- Püsivus failikirjete kujul, nagu Kafka, RocketMQ
- Tee mäluandmetest püsipilt, näiteks beanstalkd, VisiNotify
- (1), (2) ja (3) kõigil kolmel püsivusmeetodil on võimalus pikendada mälujärjekorra puhvrit ning (4) on lihtsalt mälupilt, mis suudab taastada andmeid eelmisest mälust pärast seda, kui vahendaja kõne lõpetab ja taaskäivitub.
JMS-i ja CORBA teavituse spetsifikatsioonid ei täpsusta selgelt, kuidas püsida, kuid püsivuse osa jõudlus määrab otseselt kogu sõnumi vahendustarkvara toimivuse.
RocketMQ kasutab täielikult Linuxi failisüsteemi mäluvahemälu jõudluse parandamiseks.
On mitmeid olukordi, kus sõnumi usaldusväärsus mõjutab sõnumi usaldusväärsust:
- Maakler sulgeb tavaliselt
- Maaklerikrahh
- Operatsioonisüsteemi krahh
- Masin kaotab voolu, kuid toiteallika saab kohe taastada.
- Masin ei lülitu sisse (see võib olla kahjustatud olulistele seadmetele nagu protsessor, emaplaat, mälu jne).
- Kettaseadme kahjustus.
(1), (2), (3) ja (4) on kõik olukorrad, kus riistvaralised ressursid saab kohe taastada ning RocketMQ saab tagada, et sõnumid ei kaoks ega kaotaks väikest hulka andmeid (sõltuvalt sellest, kas vilkumismeetod on sünkroonne või asünkroonne).
(5) (6) See on üksik rikkepunkt ja seda ei saa taastada, kui see on tekkinud, kaovad kõik selle punkti sõnumid. Mõlemal juhul tagab RocketMQ, et 99% sõnumitest ei kao asünkroonse replikatsiooni kaudu, kuid siiski on väga vähe sõnumeid, mis võivad kaduma minna. Sünkroonne kahe kirjutamise tehnoloogia suudab täielikult vältida üksikuid punkte, mis paratamatult mõjutavad jõudlust, muutes selle sobivaks olukordades, kus sõnumite usaldusväärsuse on äärmiselt kõrged, näiteks rahaga seotud rakendustes.
RocketMQ toetab sünkroonset dualkirjutamist alates versioonist 3.0.
Madala latentsusega sõnumid jõuavad tarbijani kohe pärast sõnumi jõudmist maaklerini, ilma et sõnumeid koguneks.
RocketMQ kasutab pika päringu tõmbe meetodit, et tagada sõnumi väga reaalajas edastamine ning reaalajas sõnumi mitte-madalam kui push-hääl.
Vähemalt üks kord tähendab, et iga sõnum tuleb kohale toimetada üks kord.
RocketMQ Consumer tõmbab esmalt sõnumi kohalikku piirkonda ja tagastab ACK-i serverisse pärast tarbimise lõppu.
Täpselt ainult korra- Sõnumi saatmise etapp ei luba saata duplikaatsõnumeid.
- Consume Message etapis ei ole lubatud tarbida duplikaatsõnumeid.
Alles siis, kui ülaltoodud kaks tingimust on täidetud, saab sõnumit pidada "täpselt ainult korraks" ning nende kahe punkti saavutamiseks tekib hajutatud süsteemi keskkonnas paratamatult suur üldkoormus. Seetõttu ei garanteeri RocketMQ seda funktsiooni kõrge jõudluse saavutamiseks ning nõuab ettevõttes duplikaatide eemaldamist, mis tähendab, et tarbija sõnumid peavad olema idempotentsed. Kuigi RocketMQ ei saa rangelt garanteerida mittedubleerimist, esineb tavatingimustes harva korduvat saatmist ja tarbimist, ainult võrgu kõrvalekaldeid, tarbija käivitamist ja peatamist ning muid ebatavalisi olukordi, näiteks sõnumite dubleerimist.
Selle probleemi peamine põhjus on see, et võrgukõnedes esineb ebakindlust, st kolmas olek, kus ei õnnestu ega ebaõnnestumine, mistõttu tekib sõnumite korduse probleem.
Mida peaksin tegema, kui maakleri puhver on täis? Maakleri puhver viitab tavaliselt maakleris oleva järjekorra mälupuhvri suurusele, mis on tavaliselt piiratud suurusega – mis siis, kui puhver on täis?
Siin on, kuidas seda CORBA teavituse spetsifikatsioonis käsitletakse:
- RejectNewEvents lükkab uue sõnumi tagasi ja tagastab RejectNewEvents veakoodi tootjale.
- Viska olemasolevad sõnumid ära vastavalt kindlale poliitikale
- AnyOrder – Iga sündmus võib ülevoolu korral kõrvale jätta. See on selle omaduse vaikimisi seadistus.
- FifoOrder – Esimene üritus, mis vastu võetakse, on esimene ära visatud.
- LifoOrder – Viimane saadetud sündmus on esimene, mis ära visatakse.
- PriorityOrder – Sündmused tuleb kõrvaldada prioriteedijärjekorras, nii et madalama prioriteediga sündmused visatakse enne kõrgema prioriteediga sündmusi ära.
- TähtaegJärjekord – Sündmused tuleks esmalt välja visata lühima kehtivusaja järjekorras.
RocketMQ-l puudub mälupuhvri kontseptsioon ning RocketMQ järjekorrad on püsivad kettad, mida andmeid puhastatakse regulaarselt.
Selle probleemi lahendamiseks on RocketMQ-l väga oluline erinevus teistest MQ-dest: RocketMQ mälupuhver on abstraktselt jaotatud lõpmatusse järjekorda, ükskõik kui palju andmeid sisse tuleb, seda saab paigaldada, see lõpmatus on olemas, maakler kustutab regulaarselt aegunud andmeid, näiteks maakler salvestab ainult 3 päeva sõnumeid, ja kuigi selle puhvri pikkus on lõpmatu, kustutatakse 3 päeva tagused andmed järjekorra lõpust.
Tagantjärele tarbimine tähendab sõnumit, mille tarbija on edukalt tarbinud, ning sõnum tuleb ärinõudluse tõttu uuesti tarbida. Näiteks tarbijasüsteemi rikke tõttu tuleb 1 tunni tagused andmed pärast taastamist uuesti tarbida, seejärel peaks maakler pakkuma mehhanismi tarbimise edenemise tagasipööramiseks vastavalt ajamõõtmele.
RocketMQ toetab ajale tuginevat retrospektiivset tarbimist, mille ajamõõtme on millisekunditele täpne ja mida saab edasi või tagasi jälgida.
Sõnumite virnastamise peamine funktsioon on asünkroonne lahutamine, teine oluline funktsioon on blokeerida esiosa andmeüleujutuse tipp ja tagada tagapõhjasüsteemi stabiilsus, mis nõuab sõnumivahendustarkvaralt teatud sõnumite virnastamise võimet ning sõnumikuhja integreerib järgmised kaks olukorda:
- Sõnumid kuhjatakse mälupuhvritesse ja kui need ületavad mälupuhvri piiri, saab sõnumeid maha jätta vastavalt kindlale langetuspoliitikale, nagu kirjeldatud CORBA teavituse spetsifikatsioonis. See sobib teenustele, mis taluvad sõnumite äraviskamist; sel juhul sõltub sõnumite kogunemisvõime peamiselt mälupuhvri suurusest ning jõudluse langus ei ole pärast sõnumi virnastamist liiga suur, sest mälus oleva andmehulga mõju välismaailmale kättesaadavusele on piiratud.
- Sõnumid kuhjuvad püsivatesse salvestussüsteemidesse nagu DB, KV salvestus, failikirje vorm. Kui sõnumeid ei saa mäluvahemälus tabada, on vältimatu pääseda kettale, mis tekitab suure hulga lugemis-IO-d, ning lugemis-IO läbilaskevõime määrab otse sõnumite ligipääsu pärast nende kuhjumist.
Sõnumite kogumisvõime hindamiseks on neli peamist punkti:
- Kui palju sõnumeid saab kuhjata, mitu baiti? See tähendab sõnumi kuhjatud mahutavust.
- Kui sõnum on kuhjatud, kas sõnumi läbilaskevõime mõjutab kuhjamine?
- Kas tarbijate tavapärane tarbimine saab pärast sõnumite kuhjumist mõjutatud?
- Kui sõnumid on kuhjatud, milline on läbilaskevõime, kui pääseb ligi kettale kuhjatud sõnumitele?
Hajutatud tehingud Mitmed tuntud hajutatud tehinguspetsifikatsioonid, nagu XA, JTA jne. Nende seas toetab XA spetsifikatsiooni laialdaselt suured andmebaasitootjad, nagu Oracle, Mysql jne. Nende seas on XA TM rakendusjuht, nagu Oracle Tuxedo, laialdaselt kasutusel finantsides, telekommunikatsioonis ja teistes valdkondades.
Hajutatud tehingud hõlmavad kaheastmelisi commit-probleeme ning andmete salvestamise mõttes tuleb toetada KV-salvestust, sest commit rollback'i teine etapp peab muutma sõnumi olekut, mis peab hõlmama sõnumi leidmist vastavalt võtmele. RocketMQ möödub teises etapis sõnumi leidmise probleemist võtme järgi, kasutades esimest astet ettevalmistatud sõnumi saatmiseks, sõnumi nihke saamiseks, ning teises etapis sõnumi ligipääsuks nihke kaudu ja muutes olekut, nihe on andmete aadress.
RocketMQ tehingute rakendamise meetod ei toimu KV-salvestuse kaudu, vaid nihutusmeetodi abil, millel on märkimisväärne puudus – andmete muutmine nihke kaudu põhjustab süsteemis liiga palju musti lehti, mis vajavad erilist tähelepanu.
Ajastatud sõnumid Ajastatud sõnumid tähendavad, et tarbijad ei saa sõnumeid tarbida kohe pärast nende saatmist maaklerile ning neid saab tarbida ainult kindlal ajahetkel või pärast kindla aja ootamist.
Kui soovid toetada suvalist ajatäpsust, pead maakleri tasandil tegema sõnumite sorteerimist, ja kui on vaja järjepidevust, toob sõnumite sorteerimine paratamatult kaasa suure jõudluskoormuse.
RocketMQ toetab ajastamist, kuid ei toeta suvalist ajatäpsust ning toetab kindlaid tasemeid, nagu ajastus 5s, 10s, 1m jne.
Sõnumi uuesti proovimine Kui tarbija ei suuda sõnumit tarbida, paku uuesti proovimise mehhanismi, et sõnum uuesti tarbiks. Tarbija tarbimissõnumite ebaõnnestumisi käsitletakse tavaliselt järgmistes olukordades:
- Sõnumi enda põhjustel, näiteks deserialiseerimise ebaõnnestumise tõttu, ei saa sõnumiandmeid töödelda (näiteks telefoniarve täitmine, praeguse sõnumi mobiilinumber on välja logitud, seda ei saa laadida) jne. See viga nõuab tavaliselt selle sõnumi vahelejätmist ja teiste sõnumite tarbimist ning see ebaõnnestunud sõnum on 99% ebaõnnestunud isegi siis, kui tarbimine proovitakse kohe uuesti, seega on parim pakkuda ajastatud kordusproovi mehhanismi, st proovida uuesti 10 sekundi pärast.
- Kuna sõltuvad allavoolu rakendusteenused on kättesaamatud, näiteks andmebaasi ühendus ei ole saadaval, on väline süsteemivõrk kättesaamatu jne. Selle vea korral, isegi kui praegune ebaõnnestunud sõnum vahele jäetakse, tarbitakse ka teisi sõnumeid. Sellisel juhul soovitatakse rakendada une 30 sekundit ja tarbida järgmine sõnum, mis võib vähendada maaklerile avaldust uuesti proovida.
RocketMQ ülevaadeVaatame, kas RocketMQ lahendab eespool mainitud sõnumite vahendustarkvara probleemid.
Mis on RocketMQ?
Ülaltoodud joonis on tüüpiline sõnumite vahendustarkvara mudel, mis saatis ja vastu sõnumeid, RocketMQ on samuti sellisel viisil üles ehitatud, lühidalt öeldes on RocketMQ-l järgmised omadused:
- See on järjekorramudeli sõnumite vahetarkvara, millel on kõrge jõudlus, kõrge töökindlus, kõrge reaalajas ja hajutatud omadused.
- Produtsent, Tarbija ja Järjekord saab kõik levitada.
- Tootja saadab omakorda sõnumeid mõnele järjekorrale, järjekorra kogumist nimetatakse Teemaks, Tarbija Kui edastab tarbimist, tarbib üks tarbija eksemplar kõik sellele teemale vastavad järjekorrad ning klastri tarbimise korral tarbivad mitu tarbija instantslit selle teema järjekorra kogumit ühtlaselt.
- Range sõnumite järjekord on garanteeritud
- Pakub rikkalikke sõnumitõmbe režiime
- Tõhusad horisontaalsed tellija skaleerimise võimalused
- Reaalajas sõnumite tellimismehhanism
- Sajad miljonid sõnumite kogumisvõime
- Vähem sõltuvust
RocketMQ füüsiline paigaldusstruktuur
Nagu ülaloleval joonisel näidatud, on RocketMQ paigaldusstruktuuril järgmised omadused:
- Name Server on praktiliselt olekuta sõlm, mida saab deployerida klastrites ilma sõlmedevahelise info sünkroniseerimiseta.
- Maakleri paigaldus on suhteliselt keeruline: maakler jaguneb meistriks ja orjaks, meister võib vastata mitmele orjale, kuid ori saab vastata ainult ühele meistrile, meistri ja orja vastavus määratletakse sama maaklerinime määramisega, erineva BrokerId-ga, BrokerId on 0 Meistri jaoks ja mitte-0 tähendab Orja. Meistriid saab kasutada ka mitmes komplektis. Iga maakler loob pika ühenduse kõigi nimeserveri klastri sõlmedega ja registreerib teemainfo kõigile nimeserveritele regulaarselt.
- Tootja loob pika ühenduse ühe nimeserveri klastri sõlmega (juhuslikult valitud), taotleb perioodiliselt teema marsruutimise infot nimeserverist, loob pika ühenduse meistriga, mis pakub teemateenust, ning saadab südamelööke meistrile regulaarsete intervallidega. Tootja on täiesti olekuta ja seda saab juurutada klastrites.
- Tarbija loob pika ühenduse ühe sõlmega nimeserveri klastris (juhuslikult valitud), hangib regulaarselt teema marsruutimise infot nimeserverist ning loob pika ühenduse Meistri ja Orjaga, kes pakuvad teemateenust, ning saadab südamelööke Meistrile ja Orjale regulaarselt. Tarbijad saavad tellida sõnumeid nii Masterilt kui Slave'ilt ning tellimusreeglid määratakse Brokeri konfiguratsiooni järgi.
RocketMQ loogiline paigaldusstruktuur
Nagu ülaltoodud joonisel näidatud, on RocketMQ loogilisel paigaldusstruktuuril kaks omadust: tootja ja tarbija.
Sõnumirakenduse esindamiseks kasutatakse Tootjagruppi, mis sisaldab mitut Tootja instantsi, mis võivad olla mitu masinat, mitmed protsessid või mitu protsessi Tootja objekti. Tootjagrupp võib saata mitu teemasõnumit ning tootjagrupp toimib järgmiselt:
- Tuvasta tootja tüüp
- Saad pärida, kas selles sõnumirakenduses on mitu tootja instantsi, kasutades O&M tööriista
- Kui saadetakse hajutatud tehingu sõnum, siis kui tootja ootamatult maha läheb, helistab maakler aktiivselt tagasi mis tahes masinale tootjagrupis, et kinnitada tehingu staatust.
Tarbijate sõnumirakenduse esindamiseks sisaldab tarbijagrupp mitut tarbijaeksemplari, mis võivad olla mitu masinat, mitu protsessi või mitmed tarbijaobjektid. Mitmed tarbijad tarbijagrupis tarbivad sõnumeid ühtlaselt jaotatuna ning kui need on seatud edastamiseks, tarbib iga instants selle tarbijagrupi all kogu andmemahtu.
RocketMQ andmesalvestusstruktuur
Nagu ülaltoodud joonisel näidatud, kasutab RocketMQ salvestusmeetodit, mis eraldab andmed indeksitest. Tõhusalt vähendada failiressursside, IO ressursside ja mäluressursside kadu. Isegi suurte andmetega nagu Alibaba võivad kõrge samaaegsuse stsenaariumid tõhusalt vähendada otsast lõpuni latentsust ja omada tugevaid horisontaalseid skaleerimisvõimalusi.
|
Postitatud 28.07.2017 20:26:52
|
|
|
|
Postitatud 29.07.2017 08:09:37