Tento článek nejprve vede k tomu, jaké problémy musí middleware pro zprávy obvykle řešit, jaké obtíže při jejich řešení vzniknou, zda lze Apache RocketMQ vyřešit jako vysoce výkonný, vysoce propustný distribuovaný middleware zpráv jako open source od Alibaba a jak jsou tyto problémy definovány ve specifikaci. Tento článek poté představí architektonický design RocketMQ, aby čtenářům rychle přiblížil RocketMQ.
1. Jaké problémy musí message middleware řešit? Publish/Subscribe je nejzákladnější funkcí middleware zpráv a je také relativní vůči tradiční komunikaci RPC. Nebudu tu zacházet do detailů.
Priorita popsaná ve specifikaci Priority zprávy se vztahuje na frontu zpráv, každá zpráva má jinou prioritu, obvykle popsanou celými čísly, zpráva s vysokou prioritou je doručena jako první; pokud je zpráva zcela v paměťové frontě, může být seřazena podle priority před doručením, aby byla doručena jako první.
Protože všechny zprávy v RocketMQ jsou trvalé, pokud jsou seřazeny podle priority, bude režijní zátěž velmi velká, takže RocketMQ výslovně nepodporuje prioritu zpráv, ale může implementovat podobné funkce jako obcházení, tedy nakonfigurovat frontu s vysokou prioritou a frontu s normální prioritou a posílat různé priority do různých front.
U prioritních otázek lze je shrnout do 2 kategorií:
- Pokud je priorita dosažena, není prioritou v přísném smyslu a priorita se obvykle dělí na vysokou, střední, nízkou nebo několik dalších úrovní. Každá priorita může být reprezentována jiným tématem a při odeslání zprávy lze specifikovat různá témata, která prioritu reprezentují, což může vyřešit většinu prioritních problémů, ale ohrozit přesnost obchodních priorit.
- Přísná priorita, priorita je vyjádřena jako celé číslo, například 0 ~ 65535, tento typ prioritního problému obecně není vhodný pro řešení s jinými tématy. Pokud chcete, aby MQ tento problém vyřešil, bude to mít velký dopad na výkon MQ. Tady je bod, který je třeba si být jistý, že firma opravdu potřebuje tuto přísnou prioritizaci, a pokud jsou priority zredukovány na pár kusů, jaký dopad to bude mít na podnik?
Pořadí zpráv označuje typ zprávy, kterou lze konzumovat v pořadí, v jakém je odeslána. Například objednávka generuje 3 zprávy, a to vytvoření objednávky, platba objednávky a dokončení objednávky. Při konzumaci je smysluplné konzumovat v tomto pořadí. Zároveň však lze objednávky konzumovat paralelně.
RocketMQ může přísně zajistit, že zprávy jsou uspořádané.
Filtrování zpráv Message FilterBroker
V Brokeru má filtrování podle požadavků spotřebitele výhodu v tom, že snižuje přenos zbytečných zpráv ke spotřebiteli.
Nevýhodou je, že zvyšuje zátěž pro makléře a je poměrně složitá na implementaci.
1. Taobao Notify podporuje různé metody filtrování, včetně přímého filtrování podle typu zprávy a flexibilního filtrování syntaxických výrazů, které mohou splnit téměř nejnáročnější potřeby filtrování.
2. Taobao RocketMQ podporuje filtrování podle jednoduchého tagu zprávy, stejně jako podle hlavičky a těla zprávy.
3. Flexibilní filtrování syntaxních výrazů je také podporováno specifikací CORBA Notification.
Filtrování zpráv na straně spotřebitele
Toto filtrování může aplikace plně přizpůsobit, ale nevýhodou je, že spotřebiteli je posíláno mnoho zbytečných zpráv.
Existuje několik běžných metod perzistence používaných pro perzistenci zpráv:
- Persistujte do databáze, například Mysql.
- Persistujte na KV úložišti, jako jsou levelDB, Berkeley DB a další systémy ukládání KV.
- Persistence ve formě souborových záznamů, jako jsou Kafka, RocketMQ
- Vytvořte trvalý obraz paměťových dat, například Beansstemd, VisiNotify
- (1), (2) a (3) všechny tři metody perzistence mají schopnost rozšiřovat paměťový buffer fronty a (4) jsou pouze obrazem paměti, který může obnovit data z předchozí paměťi i po ukončení a restartu brokera.
Specifikace JMS a CORBA Notification výslovně nespecifikují, jak udržet, ale výkon perzistenční části přímo určuje výkon celého middleware zpráv.
RocketMQ plně využívá cache souboru Linux pro zlepšení výkonu.
Existuje několik situací, kdy spolehlivost zprávy ovlivňuje spolehlivost zpráv:
- Makléř uzavírá normálně
- Krach makléře
- Pád OS
- Stroj ztrácí energii, ale zdroj energie lze okamžitě obnovit.
- Stroj se nezapne (může být poškozen klíčovými zařízeními jako CPU, základní deska, paměť atd.)
- Poškození diskového zařízení.
(1), (2), (3) a (4) jsou situace, kdy lze hardwarové zdroje okamžitě obnovit a RocketMQ může zajistit, že zprávy nejsou ztraceny nebo že je ztraceno malé množství dat (v závislosti na tom, zda je metoda flashování synchronní nebo asynchronní).
(5) (6) Jedná se o jediný bod selhání a nelze ho obnovit, jakmile k němu dojde, všechny zprávy na tomto jediném bodě jsou ztraceny. V obou případech RocketMQ zajišťuje, že 99 % zpráv není ztraceno asynchronní replikací, ale stále je velmi málo zpráv, které by mohly být ztraceny. Synchronní technologie duálního zápisu může zcela obejít jednotlivé body, což nevyhnutelně ovlivní výkon, což ji činí vhodnou pro situace s extrémně vysokými požadavky na spolehlivost zpráv, jako jsou aplikace související s penězi.
RocketMQ podporuje synchronní dvojí zápis od verze 3.0.
Nízkolatencní zprávy mohou dosáhnout spotřebitele ihned poté, co zpráva dorazí k brokerovi, bez akumulace zpráv.
RocketMQ používá metodu dlouhého dotazování, aby zajistil, že zpráva je velmi aktuální a že aktuální zpráva není nižší než u push.
Alespoň jednou znamená, že každá zpráva musí být doručena jednou.
RocketMQ Consumer nejprve stáhne zprávu do místní oblasti a poté vrátí ACK serveru po dokončení spotřeby.
Přesně jen jednou- Fáze odesílání zpráv neumožňuje odesílání duplicitních zpráv.
- Ve fázi Spotřebovat zprávy není povoleno duplicitní zprávy konzumovat.
Pouze pokud jsou splněny výše uvedené dvě podmínky, lze zprávu považovat za "Přesně pouze jednou" a k dosažení těchto dvou bodů nevyhnutelně vzniknou obrovské režie v prostředí distribuovaného systému. Proto pro dosažení vysokého výkonu RocketMQ tuto funkci nezaručuje a vyžaduje deduplikaci v podnikání, což znamená, že spotřebitelské zprávy musí být idempotentní. Ačkoliv RocketMQ nemůže striktně zaručit neduplikaci, za normálních okolností dochází jen zřídka k opakovanému odesílání a spotřebě, pouze k anomaliím sítě, startu a ukončení spotřebitele a dalším abnormálním situacím, jako je duplicita zpráv.
Hlavním důvodem tohoto problému je, že v síťových hovorech existuje nejistota, tedy třetí stav, kdy není ani úspěch, ani neúspěch, takže vzniká problém opakování zpráv.
Co mám dělat, když je Broker's Buffer plný? Buffer brokera obvykle označuje velikost paměťového bufferu fronty v brokeru, která je obvykle omezená velikostí, co když je buffer plný?
Takto je to řešeno ve specifikaci CORBA Notification:
- RejectNewEvents novou zprávu odmítne a vrátí Producentovi chybový kód RejectNewEvents.
- Vyřaďte stávající zprávy podle konkrétní politiky
- AnyOrder – Jakákoli událost může být při přetečení zahozena. Toto je výchozí nastavení této vlastnosti.
- FifoOrder – První obdržená událost bude první odložená.
- LifoOrder – Poslední přijatá událost bude první odložená.
- PriorityOrder – Události by měly být vyřazeny v pořadí priorit, aby byly události s nižší prioritou zařazeny před událostmi s vyšší prioritou.
- DeadlineOrderOrder – Události by měly být nejprve vyřazeny v pořadí nejkratšího termínu vypršení.
RocketMQ nemá koncept paměťového bufferu a fronty RocketMQ jsou trvalé disky a data jsou pravidelně vymazávána.
Pro řešení tohoto problému má RocketMQ velmi výrazný rozdíl oproti ostatním MQ – paměťový buffer RocketMQ je abstrahován do fronty s nekonečnou délkou, bez ohledu na množství dat, lze jej nainstalovat, tato nekonečnost je předpokládána, broker pravidelně maže expirovaná data, například broker ukládá pouze 3 dny zpráv, a i když je délka tohoto bufferu nekonečná, data z před 3 dnů budou smazána na konci fronty.
Retrospektivní spotřeba označuje zprávu, kterou spotřebitel úspěšně spotřeboval a kterou je třeba znovu konzumovat kvůli poptávce podniků. Například kvůli selhání spotřebitelského systému je třeba data z před 1 hodinou po obnovení znovu konsumovat, poté by měl broker poskytnout mechanismus, jak vrátit průběh spotřeby podle časového rozměru.
RocketMQ podporuje zpětnou spotřebu založenou na čase, s časovou dimenzí přesnou na milisekundy, kterou lze posunout zpět dopředu nebo zpět.
Hlavní funkcí message stacking middleware je asynchronní oddělení a další důležitou funkcí je blokovat datový přetížení front-endu a zajistit stabilitu back-end systému, což vyžaduje, aby message middleware měl určitou schopnost stackování, a message heap integruje následující dvě situace:
- Zprávy jsou hromaděny v paměťových bufferech a jakmile překročí paměťový buffer, mohou být zprávy zahazeny podle určité politiky dropu, jak je popsáno ve specifikaci CORBA Notification. Je vhodný pro služby, které dokážou tolerovat vyhazování zpráv, v tomto případě je kapacita akumulace zpráv hlavně ve velikosti paměťového bufferu a pokles výkonu nebude po vrstvení zprávy příliš velký, protože množství dat v paměti má omezený vliv na přístup poskytovaný vnějšímu světu.
- Zprávy se hromadí v trvalých úložných systémech, jako jsou databáze, KV úložiště, forma záznamů souborů. Když zprávy nelze zaregistrovat v paměťové cache, je nevyhnutelné přístup k disku, což generuje velké množství čtení IO, a propustnost čtených IO přímo určuje přístupnost zpráv po jejich nahromadění.
Existují čtyři hlavní body, jak hodnotit schopnost hromadit zprávy:
- Kolik zpráv se dá nashromáždit, kolik bajtů? Tedy kapacita sdělení.
- Po nahromadění zprávy je její propustnost ovlivněna tímto skládáním?
- Bude po hromadění zpráv ovlivněna běžná spotřeba spotřebitelů?
- Po naskládání zpráv, jaká je propustnost při přístupu ke zprávám nahromaděným na disku?
Distribuované transakce Několik známých specifikací distribuovaných transakcí, jako jsou XA, JTA atd. Mezi nimi je specifikace XA široce podporována hlavními výrobci databází, jako jsou Oracle, Mysql a další. Mezi nimi je lídr XA v implementaci TM, jako je Oracle Tuxedo, široce využíván ve financích, telekomunikacích a dalších oblastech.
Distribuované transakce zahrnují dvoustupňové problémy s commitem a pokud jde o ukládání dat, musí být podporováno ukládání KV, protože druhá fáze rollbacku commitu musí změnit stav zprávy, což musí zahrnovat nalezení zprávy podle klíče. RocketMQ obchází problém nalezení zprávy podle klíče ve druhé fázi, přičemž první stupeň se odesílá k odeslání připravené zprávy, získá offset zprávy a druhý stupeň slouží ke vstupu ke zprávě přes offset a změna stavu, offset je adresa dat.
Transakční metoda RocketMQ není prováděna přes KV úložiště, ale přes offsetovou metodu, která má významnou chybu, totiž že změna dat přes offset způsobí příliš mnoho špinavých stránek v systému, což vyžaduje zvláštní pozornost.
Plánované zprávy Plánované zprávy znamenají, že spotřebitelé nemohou zprávy konzumovat ihned po odeslání brokerovi a mohou být spotřebovány pouze v určitém časovém bodě nebo po čekání na určitý čas.
Pokud chcete podporovat libovolnou časovou přesnost na úrovni brokera, musíte dělat třídění zpráv, a pokud je v tom vytrvalost, třídění zpráv nevyhnutelně přinese obrovskou výkonnostní režii.
RocketMQ podporuje časovací zprávy, ale nepodporuje libovolnou časovou přesnost a podporuje specifické úrovně, jako je časování 5s, 10s, 1m atd.
Zkusit zprávu Poté, co spotřebitel zprávu nevyužije, poskytněte mechanismus pro opětovné zkusení, který ji opět spotřebuje. Selhání spotřebitelských sdělení o spotřebě lze obvykle považovat za následující situace:
- Kvůli samotné zprávě, například kvůli selhání deserializace, nelze samotná data zprávy zpracovat (například dobití telefonního účtu, číslo mobilního telefonu aktuální zprávy je odhlášeno, nelze jej dobít) atd. Tato chyba obvykle vyžaduje přeskočit tuto zprávu a spotřebovat další zprávy, a tato neúspěšná zpráva je z 99 % neúspěšná i při okamžitém opakování, proto je nejlepší zajistit mechanismus časovaného opakovaného pokusu, tedy opakování po 10 sekundách.
- Protože závislé služby aplikací na downstream nejsou dostupné, například připojení k databázi je nedostupné, externí systémová síť je nedostupná atd. Při této chybě, i když je aktuální neúspěšná zpráva přeskočena, budou také spotřebovány další zprávy. V takovém případě se doporučuje aplikovat sleep 30s a spotřebovat další zprávu, což může snížit tlak na brokera, aby zopakoval zprávu.
Přehled RocketMQPojďme zjistit, zda RocketMQ řeší problémy, kterým čelí výše zmíněný middleware ve zprávách.
Co je RocketMQ?
Výše uvedený obrázek je typický model middleware pro zprávy pro posílání a přijímání zpráv, RocketMQ je také navržen tímto způsobem, stručně řečeno, RocketMQ má následující vlastnosti:
- Jedná se o middleware s modelem fronty s vysokým výkonem, vysokou spolehlivostí, vysokou real-time a distribuovanými charakteristikami.
- Producent, spotřebitel i fronta mohou být všechny distribuovány.
- Producent postupně odesílá zprávy do některých front, kolekce fronty se nazývá Topic, Consumer Pokud broadcast consumption jedna spotřebitelská instance spotřebuje všechny fronty odpovídající tomuto tématu, a pokud clusterová spotřeba, více spotřebitelských instancí spotřebuje kolekci front, která odpovídá tomuto tématu.
- Lze zaručit přísné pořadí zpráv
- Poskytuje bohaté režimy pro vytahování zpráv
- Efektivní horizontální škálování účastníků
- Mechanismus předplatného zpráv v reálném čase
- Stovky milionů zpráv pro akumulaci
- Méně závislosti
Fyzická struktura nasazení RocketMQ
Jak je znázorněno na obrázku výše, struktura nasazení RocketMQ má následující charakteristiky:
- Jmenový server je prakticky bezstavový uzel, který lze nasadit v clusterech bez jakékoli synchronizace informací mezi uzly.
- Nasazení Brokeru je poměrně složité, Broker je rozdělen na Master a Slave, Master může odpovídat více Slave, ale Slave může odpovídat pouze jednomu Masteru, korespondence mezi Master a Slave je definována zadáním stejného BrokerName, různých BrokerId, BrokerId je 0 pro Master a non-0 znamená Slave. Magisterské studium může být také nasazeno ve více oborech. Každý broker naváže dlouhé spojení se všemi uzly v clusteru jmenných serverů a pravidelně registruje informace o tématech všem jmenným serverům.
- Producent naváže dlouhé spojení s jedním z uzlů v clusteru jmenného serveru (náhodně vybraným), periodicky získává informace o směrování témat z jmenného serveru, naváže dlouhé spojení s masterem, který poskytuje tematickou službu, a posílá heartbeaty masteru v pravidelných intervalech. Producer je zcela bezstavový a lze jej nasadit v clusterech.
- Uživatel naváže dlouhé spojení s jedním z uzlů v clusteru jmenného serveru (náhodně vybraným), pravidelně získává informace o směrování témat z jmenného serveru a navazuje dlouhé spojení s Masterem a Slave, kteří poskytují tematickou službu, a pravidelně posílá heartbeaty Masteru a Slave. Spotřebitelé se mohou přihlásit k odběru zpráv jak od Mastera, tak od Slave a pravidla předplatného jsou určena konfigurací Brokera.
Struktura logického nasazení RocketMQ
Jak je znázorněno na obrázku výše, logická struktura nasazení RocketMQ má dvě charakteristiky: Producenta a Spotřebitele.
Používaná k reprezentaci aplikace pro zasílání zpráv, skupina Producer obsahuje více instancí Producerů, což může být více strojů, více procesů jednoho stroje nebo více objektů Producer v procesu. Skupina producentů může posílat více zpráv o tématech a skupina funguje následovně:
- Identifikujte typ producenta
- Můžete zjistit, zda je v této aplikaci pro zprávy více instancí Producentů, pomocí nástroje O&M
- Při odeslání distribuované transakční zprávy, pokud producent neočekávaně vypadne, makléř aktivně zavolá zpět jakýkoli stroj ve skupině producentů, aby potvrdil stav transace.
Používaná k reprezentaci spotřebitelské aplikace pro zasílání zpráv, skupina spotřebitelů obsahuje více instancí spotřebitelů, což může být více strojů, více procesů nebo více spotřebitelských objektů procesu. Více spotřebitelů v jedné spotřebitelské skupině konzumuje zprávy rovnoměrně rozloženým způsobem a pokud je nastaveno vysílání, každá instance v této spotřebitelské skupině spotřebuje plné množství dat.
Struktura ukládání dat RocketMQ
Jak je znázorněno na obrázku výše, RocketMQ používá metodu ukládání dat, která odděluje data od indexů. Efektivně snížit ztrátu souborových zdrojů, IO zdrojů a paměťových zdrojů. I u obrovských dat, jako je Alibaba, mohou scénáře s vysokou souběžností efektivně snížit latenci od začátku do konce a nabídnout silné horizontální škálování.
|
Zveřejněno 28.07.2017 20:26:52
|
|
|
|
Zveřejněno 29.07.2017 8:09:37