Ta članek najprej vodi do tega, katere težave običajno mora reševati programska oprema za sporočila, s katerimi težavami se bodo srečali pri reševanju teh težav, ali je mogoče Apache RocketMQ rešiti kot visokozmogljivo, visoko prepustno distribuirano programsko programsko opremo za sporočila odprtokodno s strani Alibabe, in kako so ti problemi definirani v specifikaciji. Ta članek bo nato predstavil arhitekturno zasnovo RocketMQ, da bi bralcem omogočil hitrejše razumevanje RocketMQ.
1. Katere težave mora reševati sporočilna vmesna programska oprema? Objavi/Naroči se je najosnovnejša funkcija sporočilne vmesne programske opreme in je tudi relativna glede na tradicionalno RPC komunikacijo. Tukaj ne bom šel v podrobnosti.
Prioriteta, opisana v specifikaciji prioritete sporočil, se nanaša na vrsto sporočil, vsako sporočilo ima drugačno prioriteto, običajno opisano z celimi števili; sporočilo z visoko prioriteto je dostavljeno najprej, če je sporočilo v celoti v vrsti pomnilnika, ga je mogoče razvrstiti glede na prioriteto pred dostavo, tako da se najvišja prioriteta dostavi prva.
Ker so vsa sporočila v RocketMQ trajna, če so razvrščena po prioriteti, bo režija zelo velika, zato RocketMQ ne podpira posebej prioritete sporočil, lahko pa implementira podobne funkcije kot rešitev, torej konfigurira vrsto z visoko prioriteto in vrsto z običajno prioriteto ter pošlje različne prioritete v različne vrste.
Za prioritetna vprašanja jih lahko povzamemo v 2 kategoriji:
- Dokler je prioriteta dosežena, to ni prioriteta v strogem pomenu besede, prednost pa je običajno razdeljena na najvišjo, srednjo, nizko ali več stopenj. Vsaka prioriteta je lahko predstavljena z drugo temo, pri pošiljanju sporočila pa določite različne teme, ki predstavljajo prioriteto, kar lahko reši večino prioritetnih težav, a ogrozi natančnost poslovnih prioritet.
- Stroga prioriteta je izražena kot celo število, na primer 0 ~ 65535, tovrstni problem prioritet pa običajno ni primeren za reševanje z različnimi temami. Če želite, da MQ reši ta problem, bo to močno vplivalo na zmogljivost MQ. Tukaj je točka, da zagotovimo, da podjetje res potrebuje to strogo določanje prioritet, in če so prioritete stisnjene na malo, kakšen vpliv bo to imelo na podjetje?
Vrstni red sporočil se nanaša na vrsto sporočila, ki ga je mogoče pobrati v vrstnem redu, v katerem je poslano. Na primer, naročilo generira 3 sporočila, in sicer ustvarjanje naročila, plačilo naročila in izpolnitev naročila. Pri uživanju je smiselno uživati v tem vrstnem redu. Hkrati pa se naročila lahko porabljajo vzporedno.
RocketMQ lahko strogo zagotovi, da so sporočila urejena.
Filtriranje sporočil Message FilterBroker
V Brokerju ima filtriranje glede na zahteve potrošnika prednost, saj zmanjšuje prenos nepotrebnih sporočil potrošniku.
Slabost je, da to poveča breme za posrednika in je razmeroma zapleteno za izvedbo.
1. Taobao Notify podpira različne metode filtriranja, vključno z neposrednim filtriranjem po vrsti sporočila in prilagodljivim filtriranjem sintaktičnih izrazov, kar lahko zadovolji skoraj najzahtevnejše potrebe po filtriranju.
2. Taobao RocketMQ podpira filtriranje po preprosti oznaki sporočila ter po glavi in telesu sporočila.
3. Prilagodljivo filtriranje sintaktičnih izrazov je prav tako podprto v specifikaciji CORBA Notification.
Filtriranje sporočil na strani potrošnika
To filtriranje lahko aplikacija popolnoma prilagodi, vendar je slabost v tem, da se potrošniku pošlje veliko nepotrebnih sporočil.
Obstaja več pogostih metod trajnosti, ki jih uporablja ohranitev sporočil:
- Ohrani podatke v bazi podatkov, kot je Mysql.
- Shranjujte v shrambo KV, kot so levelDB, Berkeley DB in drugi sistemi za shranjevanje KV.
- Obstojnost v obliki datotečnih zapisov, kot so Kafka, RocketMQ
- Ustvarite trajno sliko podatkov pomnilnika, kot so beanstalkd, VisiNotify
- (1), (2) in (3) vse tri metode trajnosti imajo možnost razširitve pomnilniške vrste, in (4) so le pomnilniška slika, ki lahko še vedno obnovi podatke iz prejšnjega pomnilnika po tem, ko posrednik prekine in ponovno zažene.
Specifikaciji JMS in CORBA Notification ne določata eksplicitno, kako naj se ohrani, vendar zmogljivost dela za trajnost neposredno določa zmogljivost celotne programske opreme za sporočila.
RocketMQ v celoti izkorišča predpomnilnik datotečnega sistema Linux za izboljšanje zmogljivosti.
Obstaja več situacij, v katerih zanesljivost sporočil vpliva na zanesljivost sporočil:
- Posrednik običajno zaključi
- Zlom posrednikov
- Zrušitev operacijskega sistema
- Stroj izgubi napajanje, vendar se napajanje lahko takoj obnovi.
- Računalnik se ne vklopi (lahko je poškodovan na ključnih napravah, kot so procesor, matična plošča, pomnilnik itd.)
- Poškodba diskovne naprave.
(1), (2), (3) in (4) so vse situacije, kjer je mogoče strojne vire takoj obnoviti, RocketMQ pa lahko zagotovi, da sporočila niso izgubljena ali da se izgubi majhna količina podatkov (odvisno od tega, ali je metoda utripanja sinhrona ali asinhrona).
(5) (6) Gre za eno samo točko okvare in je ni mogoče obnoviti; ko se zgodi, so vsa sporočila na tej točki izgubljena. V obeh primerih RocketMQ zagotavlja, da 99 % sporočil ni izgubljenih zaradi asinhrone replikacije, vendar je še vedno zelo malo sporočil, ki bi se lahko izgubila. Sinhrona tehnologija dvojnega zapisovanja lahko popolnoma prepreči posamezne točke, kar neizogibno vpliva na zmogljivost, zato je primerna za situacije z izjemno visokimi zahtevami glede zanesljivosti sporočil, kot so aplikacije, povezane z denarjem.
RocketMQ podpira sinhrono dvojno pisanje od različice 3.0 naprej.
Sporočanje z nizko latenco lahko potrošnika doseže takoj po tem, ko sporočilo doseže posrednika, brez kopičenja sporočil.
RocketMQ uporablja metodo dolgega polling pulla, da zagotovi, da je sporočilo zelo v realnem času in da sporočilo v realnem času ni nižje od push.
Vsaj enkrat pomeni, da mora biti vsako sporočilo dostavljeno enkrat.
RocketMQ Consumer najprej prenese sporočilo na lokalno območje, nato pa po končani porabi vrne ack strežniku.
Natanko samo enkrat- Faza pošiljanja sporočil ne dovoljuje pošiljanja podvojenih sporočil.
- V fazi Poraba sporočil podvojenih sporočil ni dovoljeno uživati.
Šele ko sta zgornja dva pogoja izpolnjena, se sporočilo šteje za "Točno samo enkrat", in za dosego zgoraj omenjenih dveh točk bo v okolju distribuiranega sistema neizogibno nastal velik strošek. Zato RocketMQ za dosego visoke zmogljivosti te funkcije ne jamči in zahteva deduplikacijo v podjetju, kar pomeni, da morajo biti potrošniška sporočila idempotentna. Čeprav RocketMQ ne more strogo zagotavljati nepodvajanja, v običajnih okoliščinah redko pride do ponavljajočega se pošiljanja in porabe, le omrežnih nepravilnosti, zagona in ustavitve uporabnikov ter drugih nenavadnih situacij, kot je podvajanje sporočil.
Glavni razlog za ta problem je, da obstaja negotovost v omrežnih klicih, torej tretje stanje brez uspeha ali neuspeha, zato se pojavi problem ponavljanja sporočil.
Kaj naj naredim, če je Broker's Buffer poln? Posrednikov medpomnilnik običajno označuje velikost pomnilniškega medpomnilnika v vrsti v posredniku, ki je običajno omejena po velikosti, kaj če je predpomnilnik poln?
Tako je to urejeno v specifikaciji CORBA Notification:
- RejectNewEvents zavrne novo sporočilo in producentu vrne kodo napake RejectNewEvents.
- Zavrzite obstoječa sporočila v skladu s specifično politiko
- AnyOrder - Vsak dogodek se lahko zavrže ob presežku. To je privzeta nastavitev za to lastnost.
- FifoOrder - Prvi prejeti dogodek bo prvi zavržen.
- LifoOrder - Zadnji prejeti dogodek bo prvi zavržen.
- PriorityOrder – Dogodke je treba zavreči po vrstnem redu prioritet, tako da se dogodki z nižjo prioriteto zavržejo pred dogodki z višjo prioriteto.
- DeadlineOrder – Dogodki naj se zavržejo po najkrajšem roku za potek najprej.
RocketMQ nima koncepta pomnilniškega medpomnilnika, vrste RocketMQ so trajni diski, podatki pa se redno brišejo.
Za rešitev tega problema ima RocketMQ zelo pomembno razliko od drugih MQ-jev, RocketMQ-jev pomnilniški medpomnilnik je abstrahiran v neskončno dolgo vrsto, ne glede na to, koliko podatkov pride, ga je mogoče namestiti, ta neskončnost je predpostavljena, posrednik redno briše potekle podatke, na primer, posrednik shrani le 3 dni sporočil, čeprav je dolžina tega medpomnilnika neskončna, se podatki od pred 3 dnevi izbrišejo na koncu vrste.
Retrospektivna poraba se nanaša na sporočilo, da je potrošnik uspešno porabljal in da je sporočilo treba ponovno poslušati zaradi povpraševanja podjetij. Na primer, zaradi okvare potrošniškega sistema je treba podatke od pred eno uro ponovno pobrati po obnovi, nato pa mora posrednik zagotoviti mehanizem za povrnitev napredka porabe glede na časovno dimenzijo.
RocketMQ podpira retrospektivno porabo na podlagi časa, s časovno dimenzijo, natančno glede na milisekunde, ki jo je mogoče premikati naprej ali nazaj.
Glavna funkcija sporočilnega posrednika za zlaganje sporočil je asinhrono odvajanje, druga pomembna funkcija pa je blokirati vrh podatkovnega preplavljanja na sprednji strani in zagotoviti stabilnost sistema v ozadju, kar zahteva, da ima programska oprema sporočil določeno sposobnost zlaganja sporočil, pri čemer kup sporočil integrira naslednji dve situaciji:
- Sporočila se kopičijo v pomnilniške medpomnilnike, in ko presežejo pomnilniški medpomnilnik, se lahko sporočila zavržejo po določeni politiki izpuščanja, kot je opisano v specifikaciji CORBA Notification. Primeren je za storitve, ki lahko prenašajo zavračanje sporočil; v tem primeru je kapaciteta kopičenja sporočil predvsem odvisna od velikosti pomnilniškega medpomnilnika, poslabšanje zmogljivosti pa ne bo preveliko, ko je sporočilo zloženo, saj količina podatkov v pomnilniku omejeno vpliva na dostop, ki ga omogoča zunanji svet.
- Sporočila se kopičijo v trajnih shrambnih sistemih, kot so podatkovna baza, KV shramba, obrazec datotečnih zapisov. Ko sporočil ni mogoče zadati v pomnilniškem predpomnilniku, je neizogibno dostopati do diska, kar generira veliko količino bralnega vhodnega procesa, prepustnost bralnega vhodnega dela pa neposredno določa dostopnost sporočil po tem, ko so sestavljena.
Obstajajo štiri glavne točke za ocenjevanje sposobnosti kopičenja sporočil:
- Koliko sporočil se lahko nabere, koliko bajtov? To pomeni, da je sporočilo preveč obsežno.
- Ko je sporočilo nakopičeno, ali zlaganje vpliva na prepustnost sporočila?
- Ali bo normalna potrošnja potrošnikov prizadeta po kopičenju sporočil?
- Ko so sporočila nakopičena, kakšna je prepustnost pri dostopu do sporočil, ki so nakopičena na disku?
Porazdeljene transakcije Več znanih specifikacij distribuiranih transakcij, kot so XA, JTA itd. Med njimi je specifikacija XA široko podprta s strani večjih ponudnikov podatkovnih baz, kot so Oracle, Mysql itd. Med njimi je XA-jev vodilni ponudnik implementacije TM, kot je Oracle Tuxedo, ki je široko uporabljen v financah, telekomunikacijah in drugih področjih.
Porazdeljene transakcije vključujejo dvostopenjske težave s potrditvijo, kar zadeva shranjevanje podatkov, je treba podpirati shranjevanje KV, saj mora druga faza povračila potrditve spremeniti stanje sporočila, kar mora vključevati iskanje sporočila glede na ključ. RocketMQ zaobide problem iskanja sporočila glede na ključ v drugi fazi, pri čemer prvo stopnjo uporabi za pošiljanje pripravljenega sporočila, pridobi premik sporočila, druga stopnja pa za dostop do sporočila prek premika in spreminjanje stanja; premik je naslov podatkov.
Metoda implementacije transakcij v RocketMQ ni izvedena prek KV shranjevanja, temveč preko offset metode, ki ima pomembno pomanjkljivost, in sicer, da spreminjanje podatkov preko offseta povzroči preveč umazanih strani v sistemu, kar zahteva posebno pozornost.
Načrtovana sporočila Načrtovana sporočila pomenijo, da potrošniki ne morejo takoj po pošiljanju posredniku zaužiti sporočil in jih lahko porabijo le v določenem času ali po čakanju na določen čas.
Če želite podpirati poljubno časovno natančnost, morate na ravni posrednika izvajati razvrščanje sporočil, in če je prisotna vztrajnost, bo razvrščanje sporočil neizogibno povzročilo velik obremenitev zmogljivosti.
RocketMQ podpira časovna sporočila, vendar ne podpira poljubne časovne natančnosti in podpira določene nivoje, kot so časovne omejitve 5s, 10s, 1m itd.
Ponovni poskus sporočila Ko uporabnik ne uspe zaužiti sporočila, zagotovite mehanizem ponovnega poskusa, da sporočilo ponovno porabi. Neuspehe potrošniških sporočil o potrošnji običajno obravnavamo v naslednjih situacijah:
- Zaradi samega sporočila, kot je neuspeh deserializacije, podatkov sporočila ni mogoče obdelovati (na primer polnjenje telefonskega računa, mobilna številka trenutnega sporočila je odjavljena, ni mogoče napolniti) itd. Ta napaka običajno zahteva preskok tega sporočila in uporabo drugih sporočil, pri čemer je to sporočilo o neuspehu 99 % neuspešno, tudi če se poraba poskusi takoj, zato je najbolje zagotoviti mehanizem ponovnega poskusa s časom, torej ponovni poskus po 10 sekundah.
- Ker so odvisne storitve aplikacij na nižji ravni nedosegljive, kot je povezava z bazo podatkov, zunanje sistemsko omrežje je nedosegljivo itd. Ob tej napaki, tudi če je trenutno neuspešno sporočilo preskočeno, se porabijo tudi druga sporočila. V tem primeru je priporočljivo uporabiti sleep 30s in zaužiti naslednje sporočilo, kar lahko zmanjša pritisk na posrednika, da ponovno poskusi sporočilo.
Pregled RocketMQ: Ugotovimo, ali RocketMQ rešuje težave, s katerimi se sooča zgoraj omenjena programska oprema za sporočila.
Kaj je RocketMQ?
Zgornja slika je tipičen model vmesne programske opreme za sporočila, ki pošilja in prejema sporočila; RocketMQ je prav tako zasnovan na ta način; na kratko, RocketMQ ima naslednje značilnosti:
- Gre za vmesno programsko opremo z modelom sporočil v vrsti, ki ima visoko zmogljivost, visoko zanesljivost, visoko realnočasovno delovanje in porazdeljene lastnosti.
- Producent, potrošnik in čakalna vrsta se lahko vsi distribuirajo.
- Producent pošilja sporočila v nekatere vrste zapored, zbirka vrst se imenuje Tema, potrošniški poraba Če oddajna poraba porabi, ena potrošniška instanca porabi vse vrste, ki ustrezajo tej temi, in če je poraba grozda, več potrošniških instanc enakomerno porabi zbirko vrst, ki ustreza tej temi.
- Strogo zaporedje sporočil je mogoče zagotoviti.
- Omogoča bogate načine vlečenja sporočil
- Učinkovite horizontalne možnosti skaliranja naročnikov
- Mehanizem naročanja sporočil v realnem času
- Kapaciteta kopičenja stotin milijonov sporočil
- Manj odvisnosti
Fizična struktura razporejanja RocketMQ
Kot je prikazano na zgornji sliki, ima struktura postavljanja RocketMQ naslednje značilnosti:
- Imenski strežnik je praktično brezstanjsko vozlišče, ki ga je mogoče namestiti v gruče brez kakršnekoli sinhronizacije informacij med vozlišči.
- Uvedba Brokerja je razmeroma zapletena, Posrednik je razdeljen na Master in Slave, Master lahko ustreza več Slave, Slave pa lahko ustreza le enemu Masterju, korespondenca med Master in Slave pa je določena z navedbo istega BrokerName, različnega BrokerId, BrokerId je 0 za Master, non-0 pa pomeni Slave. Magistrski študiji so lahko tudi razporejeni v več. Vsak posrednik vzpostavi dolgo povezavo z vsemi vozlišči v gruči imenskih strežnikov in redno registrira informacije o temah vsem imenskim strežnikom.
- Producent vzpostavi dolgo povezavo z enim od vozlišč v gruči imenskega strežnika (naključno izbranem), občasno pridobi informacije o usmerjanju teme iz imenskega strežnika, vzpostavi dolgo povezavo z glavnim strežnikom, ki zagotavlja tematsko storitev, in pošilja srčne utripe glavnemu strežniku v rednih intervalih. Producer je popolnoma brez stanja in ga je mogoče namestiti v gruče.
- Uporabnik vzpostavi dolgo povezavo z enim od vozlišč v gruči imenskega strežnika (naključno izbranem), redno pridobiva informacije o usmerjanju tem iz imenskega strežnika in vzpostavi dolgo povezavo z glavnim in podrejenim strežnikom, ki zagotavljata tematsko storitev, ter pošilja srčne utripe glavnemu in podrejenskemu strežniku v rednih intervalih. Potrošniki se lahko naročijo na sporočila tako od glavnega kot podrejenega, pravila naročnine pa določa konfiguracija posrednika.
Logična struktura nameščanja RocketMQ
Kot je prikazano na zgornji sliki, ima logična struktura nameščanja RocketMQ dve značilnosti: Proizvajalec in Porabnik.
Za predstavitev sporočilne aplikacije Producer Group vsebuje več instanc Producerja, ki so lahko več strojev, več procesov stroja ali več Producer objektov procesa. Skupina producentov lahko pošlje več sporočil o temi, skupina pa deluje takole:
- Določite vrsto proizvajalca
- Preko orodja O&M lahko preverite, ali je v tej aplikaciji za sporočanje več instanc Producer
- Ko pošljete porazdeljeno transakcijsko sporočilo, če proizvajalec nepričakovano pade, posrednik aktivno pokliče nazaj katerokoli napravo v skupini proizvajalcev, da potrdi status transakcije.
Uporablja se za predstavitev potrošniške aplikacije za sporočanje, skupina potrošnikov vsebuje več primerkov potrošnikov, ki so lahko več strojev, več procesov ali več potrošniških objektov procesa. Več potrošnikov v skupini potrošnikov porablja sporočila enakomerno razporejeno, in če je nastavljeno za oddajanje, vsaka instanca v tej skupini potrošnikov porabi celotno količino podatkov.
Struktura shranjevanja podatkov RocketMQ
Kot je prikazano na zgornji sliki, RocketMQ uporablja metodo shranjevanja, ki ločuje podatke od indeksov. Učinkovito zmanjšati izgubo datotečnih, vhodno-vhodnih in pomnilniških virov. Tudi pri ogromnih podatkih, kot je Alibaba, lahko scenariji z visoko konkurenčnostjo učinkovito zmanjšajo zakasnitev od začetka do konca in imajo močne horizontalne možnosti skaliranja.
|
Objavljeno na 28. 07. 2017 20:26:52
|
|
|
|
Objavljeno na 29. 07. 2017 08:09:37