Tento článok najprv vedie k tomu, aké problémy musí správový middleware zvyčajne riešiť, aké ťažkosti sa pri ich riešení stretnú, či je možné Apache RocketMQ vyriešiť ako vysokovýkonný, vysokopriepustný distribuovaný message middleware ako open source spoločnosťou Alibaba a ako sú tieto problémy definované v špecifikácii. Tento článok následne predstaví architektonický dizajn RocketMQ, aby čitatelia rýchlo pochopili RocketMQ.
1. Aké problémy musí riešiť middleware na správy? Publikovať/Predplatiť je najzákladnejšia funkcia middleware správ a je tiež relatívna k tradičnej RPC komunikácii. Nebudem tu zachádzať do detailov.
Priorita opísaná v špecifikácii Priority správy sa vzťahuje na frontu správ, každá správa má inú prioritu, zvyčajne popísanú celými číslami, pričom správa s vysokou prioritou je doručená ako prvá, ak je správa úplne v pamäťovej fronte, môže byť zoradená podľa priority pred doručením, aby bola doručená ako prvá.
Keďže všetky správy v RocketMQ sú trvalé, ak sú zoradené podľa priority, režijné náklady budú veľmi veľké, takže RocketMQ špecificky nepodporuje prioritu správ, ale dokáže implementovať podobné funkcie ako obchádzku, teda nakonfigurovať frontu s vysokou prioritou a radu s normálnou prioritou, a posielať rôzne priority do rôznych front.
Pri prioritných otázkach ich možno zhrnúť do 2 kategórií:
- Pokiaľ je priorita dosiahnutá, nie je prioritou v prísnom zmysle slova a zvyčajne sa rozdeľuje na vysokú, strednú, nízku alebo niekoľko ďalších úrovní. Každá priorita môže byť reprezentovaná inou témou a pri odosielaní správy treba špecifikovať rôzne témy, ktoré predstavujú prioritu, čo môže vyriešiť väčšinu problémov priorít, ale ohroziť presnosť obchodných priorít.
- Prísna priorita, priorita sa vyjadruje ako celé číslo, napríklad 0 ~ 65535, tento typ prioritného problému zvyčajne nie je vhodný na riešenie s rôznymi témami. Ak chcete, aby MQ tento problém vyriešil, bude to mať veľký vplyv na výkon MQ. Tu je bod, aby ste sa uistili, že podnik naozaj potrebuje túto prísnu prioritizáciu, a ak sa priority zredukujú na niekoľko skupín, aký veľký vplyv to bude mať na podnikanie?
Poradie správ označuje typ správy, ktorú možno konzumovať v poradí, v akom je odoslaná. Napríklad objednávka generuje 3 správy, a to vytvorenie objednávky, platba objednávky a dokončenie objednávky. Pri konzumácii je zmysluplné konzumovať v tomto poradí. Zároveň však môžu byť objednávky konzumované paralelne.
RocketMQ môže prísne zabezpečiť, že správy sú usporiadané.
Filtrovanie správ Message FilterBroker
V Broker má filtrovanie podľa požiadaviek spotrebiteľa výhodu v znížení prenosu zbytočných správ k spotrebiteľovi.
Nevýhodou je, že zvyšuje záťaž pre makléra a je pomerne zložitá na implementáciu.
1. Taobao Notify podporuje rôzne metódy filtrovania, vrátane priameho filtrovania podľa typu správy a flexibilného filtrovania syntaktických výrazov, ktoré dokážu splniť takmer najnáročnejšie potreby filtrovania.
2. Taobao RocketMQ podporuje filtrovanie podľa jednoduchého tagu správy, ako aj podľa hlavičky a tela správy.
3. Flexibilné filtrovanie syntaktických výrazov je tiež podporované v špecifikácii CORBA Notification.
Filtrovanie správ na strane spotrebiteľa
Toto filtrovanie môže aplikácia plne prispôsobiť aplikácii, ale nevýhodou je, že spotrebiteľovi sa posiela veľa zbytočných správ.
Existuje niekoľko bežných metód perzistencie používaných pri perzistencii správ:
- Udržať v databáze, napríklad Mysql.
- Persistovať do KV úložiska, ako sú levelDB, Berkeley DB a ďalšie KV úložné systémy.
- Pretrvávanie vo forme súborových záznamov, ako sú Kafka, RocketMQ
- Vytvorte perperentný obraz pamäťových dát, napríklad beansstemd, VisiNotify
- (1), (2) a (3) všetky tri metódy perzistencie majú schopnosť rozšíriť pamäťový buffer fronty a (4) sú len pamäťovým obrazom, ktorý dokáže obnoviť dáta z predchádzajúcej pamäte aj po zložení a reštarte brokera.
Špecifikácie JMS a CORBA Notification explicitne nešpecifikujú, ako pretrvať, ale výkon perzistencie priamo určuje výkon celého middleware správ.
RocketMQ plne využíva cache súborového systému Linuxu na zlepšenie výkonu.
Existuje niekoľko situácií, v ktorých spoľahlivosť správ ovplyvňuje spoľahlivosť správ:
- Maklér uzatvára bežne
- Krach makléra
- Pád OS
- Stroj stratí napájanie, ale napájanie sa dá okamžite obnoviť.
- Stroj sa nezapne (môže byť poškodený na kľúčových zariadeniach ako CPU, základná doska, pamäť a pod.)
- Poškodenie zariadenia na disku.
(1), (2), (3) a (4) sú situácie, kde je možné hardvérové zdroje okamžite obnoviť a RocketMQ môže zabezpečiť, že správy nebudú stratené alebo že sa stratí malé množstvo dát (v závislosti od toho, či je metóda flashovania synchronná alebo asynchrónna).
(5) (6) Ide o jediný bod zlyhania a nedá sa obnoviť, akonáhle nastane, všetky správy na tomto jednom bode sa stratia. V oboch prípadoch RocketMQ zabezpečuje, že 99 % správ sa nestratí asynchrónnou replikáciou, no stále existuje len veľmi málo správ, ktoré môžu byť stratené. Technológia synchronného dvojitého zápisu dokáže úplne zabrániť jednotlivým bodom, čo nevyhnutne ovplyvní výkon, čo ju robí vhodnou pre situácie s extrémne vysokými požiadavkami na spoľahlivosť správ, ako sú aplikácie súvisiace s peniazmi.
RocketMQ podporuje synchronné dvojité písanie od verzie 3.0.
Správa s nízkou latenciou môže dosiahnuť spotrebiteľa okamžite po tom, čo správa dorazí k sprostredkovateľovi, bez akumulácie správ.
RocketMQ používa metódu dlhého polling pull, aby zabezpečil, že správa je veľmi aktuálna a že správa v reálnom čase nie je nižšia ako pri push.
Aspoň raz znamená, že každá správa musí byť doručená raz.
RocketMQ Consumer najprv stiahne správu do lokálnej oblasti a potom po dokončení spotreby vráti ACK serveru.
Presne len raz- Fáza odosielania správ neumožňuje odosielanie duplicitných správ.
- V štádiu Spotrebovať správu nie je povolené konzumovať duplicitné správy.
Len keď sú splnené vyššie uvedené dve podmienky, môže byť správa považovaná za "Presne iba raz" a na dosiahnutie týchto dvoch bodov nevyhnutne vzniknú obrovské režijné náklady v prostredí distribuovaného systému. Preto na dosiahnutie vysokého výkonu RocketMQ túto funkciu nezaručuje a vyžaduje deduplikáciu v podnikaní, čo znamená, že spotrebiteľské správy musia byť idempotentné. Hoci RocketMQ nemôže striktne zaručiť neduplikáciu, za normálnych okolností dochádza len zriedka k opakovanému odosielaniu a konzumácii, iba k abnormalitám siete, štartu a zastaveniu spotrebiteľa a ďalším abnormálnym situáciám, ako je duplikácia správ.
Základným dôvodom tohto problému je, že v sieťových volaniach existuje neistota, teda tretí stav ani úspechu, ani neúspechu, takže vzniká problém opakovania správ.
Čo mám robiť, ak je Broker's Buffer plný? Buffer brokera zvyčajne označuje veľkosť pamäťového bufferu fronty v brokerovi, ktorá je zvyčajne obmedzená veľkosťou, čo ak je buffer plný?
Takto je to riešené v špecifikácii CORBA Notification:
- RejectNewEvents novú správu odmietne a vráti chybový kód RejectNewEvents producentovi.
- Vyraďte existujúce správy podľa konkrétnej politiky
- AnyOrder - Akákoľvek udalosť môže byť pri pretečení zahodená. Toto je predvolené nastavenie pre túto vlastnosť.
- FifoOrder - Prvá udalosť, ktorú získate, bude prvou zahodenú.
- LifoOrder - Posledná prijatá udalosť bude prvou zahodenou.
- PriorityOrder – Udalosti by sa mali zahodiť v poradí priority, aby boli udalosti s nižšou prioritou zahodené pred udalosťami s vyššou prioritou.
- DeadlineOrderOrder – Udalosti by sa mali najskôr vyradiť v poradí najkratšej expirácie.
RocketMQ nemá koncept pamäťového bufferu a fronty RocketMQ sú perzistentné disky, pričom dáta sa pravidelne vymazávajú.
Na riešenie tohto problému má RocketMQ veľmi výrazný rozdiel oproti ostatným MQ – pamäťový buffer RocketMQ je abstrahovaný do nekonečne dlhého frontu, bez ohľadu na to, koľko dát príde, môže byť nainštalovaný, táto nekonečnosť je predpokladaná, broker pravidelne maže expirované dáta, napríklad broker uloží len 3 dni správ, a hoci je dĺžka tohto bufferu nekonečná, dáta spred 3 dní budú vymazané z konca fronty.
Retrospektívna spotreba označuje správu, že spotrebiteľ úspešne skonzumoval a táto správa je potrebné znovu skonzumovať kvôli dopytu podnikania. Napríklad v dôsledku zlyhania spotrebiteľského systému je potrebné po obnovení spotrebovať údaje spred 1 hodiny, potom by mal maklér poskytnúť mechanizmus na vrátenie postupu spotreby podľa časovej dimenzie.
RocketMQ podporuje retrospektívnu spotrebu na základe času, s časovým rozmerom presným na milisekundy, ktoré je možné spätne posunúť dopredu alebo dozadu.
Hlavnou funkciou message stacking middleware je asynchrónne oddelenie a ďalšou dôležitou funkciou je blokovať dátový presun front-endu a zabezpečiť stabilitu back-end systému, ktorý vyžaduje, aby message middleware mal určitú schopnosť stackovania správ, pričom message heap integruje nasledujúce dve situácie:
- Správy sa hromadia v pamäťových bufferoch a keď prekročia pamäťový buffer, správy môžu byť zahodené podľa určitej politiky dropu, ako je popísané v špecifikácii CORBA Notification. Je vhodný pre služby, ktoré dokážu tolerovať zahadzovanie správ, v tomto prípade akumulačná kapacita správ spočíva hlavne vo veľkosti pamäťového bufferu a pokles výkonu nebude po vrstvení správy príliš veľký, pretože množstvo dát v pamäti má obmedzený vplyv na možnosť prístupu k vonkajšiemu svetu.
- Správy sa hromadia v trvalých úložných systémoch, ako sú databázy, KV úložisko, forma záznamov súborov. Keď správy nie je možné trafiť do pamäťovej vyrovnávacej pamäte, je nevyhnutné pristupovať k disku, čo generuje veľké množstvo čítaného IO, a priepustnosť čítaných IO priamo určuje prístupnosť správ po ich nahromadení.
Existujú štyri hlavné body na hodnotenie schopnosti zhromažďovania správ:
- Koľko správ sa dá nahromadiť, koľko bajtov? Teda kapacita posolstva.
- Po nahromadení správy, ovplyvňuje toto vrstvenie priepustnosť správy?
- Ovplyvní sa bežná spotreba spotrebiteľov po tom, čo sa správy nahromadia?
- Po nahromadení správ, aká je priepustnosť pri prístupe k správam nahromadeným na disku?
Distribuované transakcie Niekoľko známych špecifikácií distribuovaných transakcií, ako napríklad XA, JTA a podobne. Medzi nimi je špecifikácia XA široko podporovaná hlavnými dodávateľmi databáz, ako sú Oracle, Mysql a ďalší. Medzi nimi je lídrom XA v implementácii TM, ako je Oracle Tuxedo, ktorý je široko využívaný vo financiách, telekomunikáciách a ďalších oblastiach.
Distribuované transakcie zahŕňajú dvojstupňové problémy s commitom a z hľadiska ukladania dát musí byť podporované ukladanie KV, pretože druhá fáza rollbacku commitu musí upraviť stav správy, čo musí zahŕňať akciu hľadania správy podľa kľúča. RocketMQ obchádza problém hľadania správy podľa kľúča v druhej fáze, pričom používa prvú fázu na odoslanie pripravenej správy, získanie offsetu správy a druhú fázu na prístup k správe cez offset a úpravu stavu, offset je adresa dát.
Metóda implementácie transakcií v RocketMQ sa nerealizuje cez KV úložisko, ale cez offsetovú metódu, ktorá má významnú chybu, a to že zmena dát cez offset spôsobí príliš veľa špinavých stránok v systéme, čo si vyžaduje osobitnú pozornosť.
Plánované správy Plánované správy znamenajú, že spotrebitelia nemôžu spotrebovať správy okamžite po odoslaní sprostredkovateľovi a môžu byť spotrebované iba v konkrétnom časovom bode alebo po čakaní na určitý čas.
Ak chcete podporiť ľubovoľnú presnosť času, na úrovni brokera musíte robiť triedenie správ, a ak je v tom vytrvalosť, triedenie správ nevyhnutne prinesie veľké výkonnostné náklady.
RocketMQ podporuje časové správy, ale nepodporuje ľubovoľnú presnosť času a podporuje špecifické úrovne, ako sú časovanie 5s, 10s, 1m a podobne.
Opätovné skúsenie správy Po tom, čo spotrebiteľ nedokáže správu spotrebovať, poskytnite mechanizmus opätovného pokusu, ktorý správu opäť spotrebuje. Zlyhania správ o spotrebiteľskej spotrebe možno zvyčajne posudzovať v nasledujúcich situáciách:
- Z dôvodu samotnej správy, ako je zlyhanie deserializácie, nie je možné spracovať samotné údaje správy (napríklad dobíjanie telefónnej faktúry, číslo mobilného telefónu aktuálnej správy je odhlásené, nemožno ho dobit) a podobne. Táto chyba zvyčajne vyžaduje preskočiť túto správu a spotrebovať ďalšie správy, a táto neúspešná správa je na 99 % neúspešná, aj keď sa spotreba okamžite zopakuje, preto je najlepšie zabezpečiť časovaný mechanizmus opakovania, teda opätovné skúšanie po 10 sekundách.
- Pretože závislé downstream aplikačné služby nie sú dostupné, napríklad pripojenie do databázy je nedostupné, externá systémová sieť je nedostupná a podobne. Pri tejto chybe, aj keď je aktuálna neúspešná správa preskočená, spotrebujú sa aj ďalšie správy. V takom prípade sa odporúča použiť režim spánku 30 sekúnd a spotrebovať ďalšiu správu, čo môže znížiť tlak na sprostredkovateľa, aby správu skúšal znova.
Prehľad RocketMQPoďme zistiť, či RocketMQ rieši problémy, ktorým čelí vyššie spomenutý middleware na správy.
Čo je RocketMQ?
Vyššie uvedený obrázok je typickým modelom middleware správ, ktorý posiela a prijíma správy, RocketMQ je tiež navrhnutý týmto spôsobom, stručne povedané, RocketMQ má nasledujúce charakteristiky:
- Ide o middleware s modelom fronty a správami s vysokým výkonom, vysokou spoľahlivosťou, vysokým reálnym časom a distribuovanými charakteristikami.
- Producent, spotrebiteľ a fronta môžu byť všetky distribuované.
- Producent posiela správy do niektorých frontov postupne, kolekcia fronty sa nazýva Topic, Consumer Ak broadcast spotreba, jedna spotrebiteľská inštancia spotrebuje všetky fronty zodpovedajúce tejto téme, a ak clusterová spotreba, viaceré spotrebiteľské inštancie spotrebujú kolekciu frontov zodpovedajúcu tejto téme rovnomerne.
- Prísne poradie správ môže byť zaručené
- Poskytuje bohaté režimy sťahovania správ
- Efektívne horizontálne škálovanie odberateľov
- Mechanizmus odberu správ v reálnom čase
- Stovky miliónov správ na akumuláciu
- Menšia závislosť
Fyzická štruktúra nasadenia RocketMQ
Ako je znázornené na obrázku vyššie, štruktúra nasadenia RocketMQ má nasledujúce charakteristiky:
- Name Server je prakticky bezstavový uzol, ktorý je možné nasadiť v klastroch bez akejkoľvek synchronizácie informácií medzi uzlami.
- Nasadenie Brokera je pomerne zložité, Broker je rozdelený na Master a Slave, Master môže zodpovedať viacerým Slave, ale Slave môže zodpovedať len jednému Masterovi, korešpondencia medzi Master a Slave je definovaná zadaním rovnakého BrokerName, rôzneho BrokerId, BrokerId je 0 pre Mastera a non-0 znamená Slave. Magisterské štúdium môže byť tiež nasadzované vo viacerých oblastiach. Každý broker nadviaže dlhé spojenie so všetkými uzlami v klastri Name Server a pravidelne registruje informácie o témach všetkým Name Serverom.
- Producent nadviaže dlhé spojenie s jedným z uzlov v klastri Name Server (náhodne vybraným), pravidelne získava informácie o smerovaní tém z Name Servera, nadväzuje dlhé spojenie s masterom, ktorý poskytuje tematickú službu, a posiela heartbeaty masteru v pravidelných intervaloch. Producer je úplne bezstavový a môže byť nasadený v klastroch.
- Spotrebiteľ nadviaže dlhé spojenie s jedným z uzlov v klastri Name Server (náhodne vybraným), pravidelne získava informácie o smerovaní tém z Name Servera a nadväzuje dlhé spojenie s Masterom a Slave, ktorí poskytujú tematickú službu, a posiela heartbeaty Masterovi a Slaveovi v pravidelných intervaloch. Spotrebitelia sa môžu prihlásiť na odber správ od Mastera aj Slave a pravidlá predplatného sú určené konfiguráciou Brokera.
Štruktúra logického nasadenia RocketMQ
Ako je znázornené na obrázku vyššie, logická štruktúra nasadenia RocketMQ má dve charakteristiky: Producent a Spotrebiteľ.
Používaná na reprezentáciu aplikácie na správu správ, skupina Producent obsahuje viacero inštancií Producentov, čo môže byť viacero strojov, viacero procesov stroja alebo viacero objektov Producenta v procese. Producentská skupina môže posielať viacero tematických správ a Producentská skupina funguje nasledovne:
- Identifikujte typ producenta
- Môžete sa opýtať, či v tejto aplikácii na správy je viacero inštancií Producenta cez nástroj O&M
- Pri odosielaní správy o distribuovanej transakcii, ak producent nečakane vypadne, maklér aktívne zavolá späť akýkoľvek stroj v skupine producentov, aby potvrdil stav transakcie.
Používaná na reprezentáciu spotrebiteľskej aplikácie na zasielanie správ, spotrebiteľská skupina obsahuje viacero inštancií spotrebiteľov, čo môže byť viacero strojov, viacero procesov alebo viacero spotrebiteľských objektov procesu. Viacerí spotrebitelia v spotrebiteľskej skupine spotrebujú správy rovnomerne rozdeleným spôsobom a ak sú nastavené na vysielanie, každá inštancia v rámci tejto spotrebiteľskej skupiny spotrebuje celé množstvo dát.
Štruktúra úložiska dát RocketMQ
Ako je znázornené na obrázku vyššie, RocketMQ používa metódu ukladania, ktorá oddeľuje dáta od indexov. Efektívne znížiť stratu súborových zdrojov, IO zdrojov a pamäťových zdrojov. Aj pri obrovských dátach ako Alibaba môžu scenáre s vysokou súbežnosťou efektívne znížiť latenciu od začiatku do konca a majú silné horizontálne škálovateľné schopnosti.
|
Zverejnené 28. 7. 2017 20:26:52
|
|
|
|
Zverejnené 29. 7. 2017 8:09:37