Ez a cikk először arra vezet, hogy általában milyen problémákat kell megoldania az üzenetközmű szoftvereknek, milyen nehézségekkel találkoznak ezek megoldása, hogy az Apache RocketMQ megoldható-e az Alibaba által nagy teljesítményű, nagy áteresztőképességű elosztott üzenetközműként nyílt forráskódú szoftverként, illetve hogyan definiálják ezeket a problémákat a specifikációban. Ez a cikk ezután bemutatja a RocketMQ architektúra tervezését, hogy az olvasók gyorsan megértsék a RocketMQ-t.
1. Milyen problémákat kell megoldania az üzenetközmű szoftvernek? A publish/subscribe az üzenetközmű legalapvetőbb funkciója, és viszonyítja a hagyományos RPC kommunikációt is. Nem megyek bele a részletekbe.
Az Üzenetprioritás specifikációban leírt prioritás egy üzenetsorra utal, minden üzenetnek más-más prioritása van, általában egész számokkal írják le, a magas prioritású üzenetet kézbesítik először, ha az üzenet teljesen memóriasorban van, akkor a továbbítás előtti prioritás szerint rendezhető, így a magas prioritás előbb érkezik.
Mivel a RocketMQ összes üzenete tartós, ha prioritás szerint rendezik őket, a túlterhelés nagyon nagy lesz, így a RocketMQ nem támogatja kifejezetten az üzenetprioritást, de hasonló funkciókat képes megoldásként megvalósítani, vagyis konfigurálhat egy magas prioritású sort, egy normál prioritású sort, és különböző prioritásokat küld különböző sorokba.
A prioritási kérdések esetében két kategóriába sorolhatók:
- Amíg a prioritás elérhető, az nem szigorú értelemben prioritás, és általában magas, közepes, alacsony vagy több további szintre osztják. Minden prioritás egy másik témával képviselhető, és üzenet küldésekor különböző témákat jelölhetnek meg az prioritás képviseletére, ami megoldhatja a legtöbb prioritási problémát, de veszélyeztetheti az üzleti prioritások pontosságát.
- Szigorú prioritás, a prioritás egész számban fejezzük ki, például 0 ~ 65535, ez a fajta prioritási probléma általában nem alkalmas különböző témák megoldására. Ha azt szeretnéd, hogy az MQ megoldja ezt a problémát, az nagyon nagy hatással lesz az MQ teljesítményére. Itt egy pont, hogy biztosan megbizonyosodjunk arról, hogy a vállalkozásnak valóban szüksége van erre a szigorú priorizálásra, és ha ezek a prioritások kevéssé sűrítik, mekkora hatással lesz ez az üzletre?
Az üzenetsorrend olyan üzenettípust jelent, amely a küldés sorrendjében fogyasztható. Például egy megbízás 3 üzenetet generál, nevezetesen rendelés létrehozását, rendelés kifizetését és rendelés befejezését. Fogyasztás közben értelmes ebben a sorrendben fogyasztani. Ugyanakkor a rendelések párhuzamosan is fogyaszthatók.
A RocketMQ szigorúan biztosítani tudja, hogy az üzenetek rendezettek legyenek.
Message FilterBroker Üzenetszűrés
A Broker esetében a fogyasztó igényei szerinti szűrés előnye az illetlen üzenetek továbbítását a fogyasztónak.
Hátránya, hogy növeli a bróker terhét, és viszonylag bonyolult a megvalósítása.
1. A Taobao Notify számos szűrési módszert támogat, beleértve a közvetlen üzenettípus szerinti szűrést és a rugalmas szintaxiskifejezés-szűrést, amely szinte a legigényesebb szűrési igényeket is kielégíti.
2. A Taobao RocketMQ támogatja a szűrést egyszerű Message Tag, valamint Message Header és body segítségével.
3. A rugalmas szintaxiskifejezés-szűrés is támogatott a CORBA Notification specifikációban.
Fogyasztói oldali üzenetszűrés
Ezt a szűrést az alkalmazás teljesen testreszabhatja, de hátránya, hogy sok haszontalan üzenetet küldenek a fogyasztónak.
Több gyakori kitartási módszer létezik az üzenet tartósságában:
- Persist adatbázisban, például Mysql-ben.
- Tartósan KV tárolásra, például levelDB, Berkeley DB és más KV tárolórendszerekre.
- Kitartás fájl formájában, mint például Kafka, RocketMQ
- Készíts egy tartós képet a memória adatairól, például beanstalkd, VisiNotify
- (1), (2) és (3) mindhárom kitartó módszer képes kiterjeszteni a memóriasor-puffert, és (4) csupán memóriakép, amely még mindig visszaállíthatja az adatokat az előző memóriából, miután a közvetítő leteszi a telefont és újraindítja.
A JMS és CORBA értesítési specifikációk nem határozzák meg kifejezetten, hogyan kell a tartósságot megtartani, de a tartósság teljesítménye közvetlenül határozza meg az egész üzenetközmű teljesítményét.
A RocketMQ teljes mértékben használja a Linux fájlrendszer memória gyorsítótárát a teljesítmény javítása érdekében.
Számos helyzet van, ahol az üzenet megbízhatósága befolyásolja az üzenetek megbízhatóságát:
- A bróker rendesen zár
- Ügynöki összeomlás
- OS összeomlás
- A gép áramot veszít, de az áramellátást azonnal visszalehet állítani.
- A gép nem kapcsol be (előfordulhat, hogy a kulcsfontosságú eszközök, például CPU, alaplap, memória stb. sérült).
- Lemezeszköz károsodás.
(1), (2), (3) és (4) mind olyan helyzetek, ahol hardveres erőforrásokat azonnal vissza lehet nyerni, és a RocketMQ biztosítja, hogy az üzenetek ne veszjenek el, vagy ne vesznek el kis mennyiségű adat (attól függően, hogy a villogási módszer szinkron vagy aszinkron).
(5) (6) Ez egyetlen hibás pont, és nem lehet visszanyerni, ha ez bekövetkezik, az egyetlen ponton lévő összes üzenet elveszik. Mindkét esetben a RocketMQ biztosítja, hogy az üzenetek 99%-a ne veszjen el aszinkron replikáció miatt, de még mindig nagyon kevés üzenet veszhet el. A szinkron kettős írás technológia teljesen elkerülheti az egyetlen pontokat, ami elkerülhetetlenül befolyásolja a teljesítményt, így alkalmassá teszi rendkívül magas üzenet-megbízhatósági igényekkel, például pénzhez kapcsolódó alkalmazásokkal.
A RocketMQ támogatja a szinkron kettős írást a 3.0-s verziótól kezdődően.
Az alacsony késleltetésű üzenetküldés közvetlenül a bróker eljutása után elérheti a fogyasztót anélkül, hogy üzenetek felhalmoznának.
A RocketMQ hosszú polling pull módszert alkalmaz, hogy biztosítsa, hogy az üzenet nagyon valós idejű legyen, és a valós idejű üzenet ne legyen alacsonyabb a push-nál.
Legalább egyszer azt jelenti, hogy minden üzenetet egyszer kell kézbesíteni.
A RocketMQ Consumer először a helyi területre húzza az üzenetet, majd a fogyasztás befejezése után visszaadja az ack-et a szervernek.
Pontosan csak egyszer- Az üzenetküldési szakasz nem engedélyezi duplikált üzenetek küldését.
- Az Üzenet fogyasztása szakaszban a duplikált üzenetek fogyasztása nem engedélyezett.
Csak akkor tekinthető az üzenet "Pontosan Csak egyszer" (Pontosan Csak egyszer), és a fenti két pont eléréséhez elkerülhetetlenül hatalmas többletterhelés keletkezik az elosztott rendszer környezetében. Ezért a magas teljesítmény eléréséhez a RocketMQ nem garantálja ezt a funkciót, és megköveteli a deduplikálást az üzletben, ami azt jelenti, hogy a fogyasztói üzeneteknek idempotensnek kell lenniük. Bár a RocketMQ nem tudja szigorúan garantálni a nem-duplikálást, normál körülmények között ritkán fordulnak elő ismétlődő küldés és fogyasztás, csak hálózati rendellenességek, fogyasztói indítás és leállítás, valamint egyéb rendellenes helyzetek, például üzenetek duplikálása.
Ennek a problémának az alapvető oka, hogy a hálózati hívásokban bizonytalanság van, vagyis a harmadik állapot, ahol sem sikeres, sem kudarc, így felmerül az üzenet ismétlésének problémája.
Mit tegyek, ha a Broker's Buffer tele van? A bróker pufferje általában a brókerben lévő sor memória puffer méretét jelenti, amely általában korlátozott, mi van, ha a puffer tele van?
Így kezelik ezt a CORBA értesítési specifikációjában:
- A RejectNewEvents elutasítja az új üzenetet, és visszaadja a RejectNewEvents hibakódot a Producernek.
- A meglévő üzenetek eldobása egy adott szabályzat szerint
- AnyOrder – Bármilyen esemény eldobható a túlcsorduláskor. Ez az alapértelmezett beállítás ehhez a tulajdonsághoz.
- FifoOrder – Az első kapott esemény az első, eldobott lesz.
- LifoOrder – Az utolsó kapott esemény lesz az első, eldobva.
- PriorityOrder – Az eseményeket prioritási sorrendben kell eldobni, így az alacsonyabb prioritású eseményeket előbb eldobják.
- DeadlineOrder – Az eseményeket először a legrövidebb lejárati határidő sorrendjében kell eldobni.
A RocketMQ-nak nincs megvan a memóriapuffer fogalmát, és a RocketMQ sorai állandó lemezek, amelyeket rendszeresen törölnek.
A probléma megoldása érdekében a RocketMQ nagyon jelentős különbséggel rendelkezik más MQ-któl: a RocketMQ memória pufferje egy végtelen hosszú sorba van osztva, függetlenül attól, mennyi adat érkezik, telepíthető, ez a végtelen megalapozott, a közvetítő rendszeresen törli a lejárt adatokat, például a bróker csak 3 napnyi üzenetet ment, és bár a puffer hossza végtelen, a 3 nappal ezelőtti adatokat törölni fogja a sor végéről.
A visszatekintő fogyasztás azt az üzenetet jelenti, amelyet a fogyasztó sikeresen fogyasztott, és az üzenetet az üzleti igény miatt újra kell fogyasztani. Például a fogyasztói rendszer meghibásodása miatt az 1 órával ezelőtti adatokat a helyreállítás után újra kell felhasználni, majd a brókernek kell olyan mechanizmust biztosítania a fogyasztási előrehaladás visszafordítására az idődimenzió szerint.
A RocketMQ időalapú visszatekintő fogyasztást támogat, egy milliszekundumos pontosságú idődimenzióval, amely előre vagy vissza lehet vezetni.
Az üzenethalmozó üzenetközmű fő funkciója az aszinkron lecsatolás, és egy másik fontos funkció a front-end adatáradás csúcsának blokkolása, valamint a háttérrendszer stabilitásának biztosítása, amely megköveteli az üzenetközmű szoftverének egy bizonyos üzenethalmozási képességet, és az üzenethalom a következő két helyzetet integrálja:
- Az üzenetek memóriapufferekben halmozódnak, és ha túllépik a memóriapuffert, az üzenetek egy bizonyos eldobási szabályzat szerint eldobhatók, ahogy azt a CORBA értesítés specifikációja leírja. Alkalmas olyan szolgáltatásoknak, amelyek elviselik az üzenetek eldobását; ebben az esetben az üzenetek felhalmozódási kapacitása főként a memória puffer méretében rejlik, és a teljesítményromlás nem lesz túl nagy az üzenet felhalmozása után, mivel a memóriaban lévő adatmennyiség korlátozott hatással van a külvilág számára biztosított hozzáférésre.
- Az üzenetek állandó tárolórendszerekben halmozódnak, mint például a DB, KV tároló, fájl nyilvántartási űrlap. Ha az üzeneteket nem lehet elérni a memória gyorsítótárban, elkerülhetetlen hozzáférni a lemezhez, ami nagy mennyiségű olvasási IO-t generál, és az olvasási IO áteresztőképessége közvetlenül határozza meg az üzenetek hozzáférési képességét a halmozódás után.
Négy fő szempont van az üzenetfelhalmozódás képességének értékelésére:
- Hány üzenetet lehet felhalmozni, hány bájt? Vagyis az üzenet hatalmas kapacitása.
- Miután egy üzenetet halmoznak, befolyásolja az üzenet áteresztőképessége a halmozás?
- Változik-e a fogyasztók normál fogyasztása, miután az üzenet felhalmozódik?
- Miután az üzenetek felhalmozódnak, mekkora az áteresztőképesség, amikor a meghajtón felhalmozódott üzeneteket érjük el?
Elosztott tranzakciók Számos ismert elosztott tranzakciós specifikáció, mint például XA, JTA stb. Közülük az XA specifikációt széles körben támogatják a nagy adatbázis-gyártók, mint az Oracle, Mysql stb. Közülük az XA TM megvalósítási vezetője, mint az Oracle Tuxedo, széles körben használják pénzügyben, távközlésben és más területeken.
Az elosztott tranzakciók kétfázisú commitációs problémákat jelentenek, és az adattárolás szempontjából a KV tárolást támogatni kell, mert a commit visszafordításának második szakasza módosítani kell az üzenet állapotát, ami magában foglalja az üzenet megtalálását a kulcs szerint. A RocketMQ megkerüli a második fokozatban a kulcs szerinti üzenet megtalálásának problémáját, az első fokozatot használja az előkészített üzenet elküldéséhez, az üzenet eltolódásának megszerzéséhez, a második fokozatot pedig az üzenethez való hozzáféréshez az eltoláson keresztül és az állapot módosításához, az eltolás az adatok címe.
A RocketMQ tranzakciós megvalósítási módszere nem KV tároláson keresztül történik, hanem az offset módszerrel, amelynek jelentős hibája van, vagyis az adatok átváltása túl sok piszkos oldalt okoz a rendszerben, ami különös figyelmet igényel.
Ütemezett üzenetek Az ütemezett üzenetek azt jelentik, hogy az üzeneteket a fogyasztók nem fogyaszthatják el közvetlenül a brókernek való elküldésük után, és csak egy adott időpontban vagy egy adott időpont megvárása után fogyaszthatók el.
Ha szeretnéd támogatni az önkényes időpontosságot, a bróker szinten üzenetrendezést kell végezni, és ha kitartóság is szükséges, akkor az üzenetrendezés elkerülhetetlenül hatalmas teljesítményterheléssel jár.
A RocketMQ támogatja az időzítési üzeneteket, de nem támogatja az tetszőleges időpontosságot, és bizonyos szinteket támogat, például 5s, 10s, 1m időzítést stb.
Üzenet újrapróbálása Miután a fogyasztó nem használja fel az üzenetet, adj egy újrapróbálkozási mechanizmust, hogy az üzenet újra elhasználjon. A fogyasztói fogyasztási üzenet hibáit általában az alábbi helyzetekben lehet figyelembe venni:
- Az üzenet okának okából, például a deserializációs hiba miatt az üzenetadatok nem feldolgozhatók (például a telefonszámla feltöltése, az aktuális üzenet mobilszáma ki van jelentkezve, nem tölthető), stb. Ez a hiba általában ezt az üzenetet kihagyja és más üzenetek fogyasztását igényli, és ez a sikertelen üzenet 99%-ban sikertelen, még akkor is, ha a fogyasztást azonnal újra próbálják, ezért a legjobb időzített újrapróbálkozási mechanizmust biztosítani, vagyis 10 másodperc után újrapróbálni.
- Mivel a függő alsó áramú alkalmazásszolgáltatások nem elérhetők, például a DB kapcsolat nem elérhető, a külső rendszerhálózat elérhetetlen stb. Ha ez a hiba felmerül, még ha a jelenlegi hibás üzenetet is kihagyjuk, más üzenetek is elmerülnek. Ebben az esetben ajánlott alvó 30-as másodperceket alkalmazni és a következő üzenetet használni, ami csökkentheti a bróker nyomását, hogy újra próbálja az üzenetet.
RocketMQ áttekintéseNézzük meg, hogy a RocketMQ megoldja-e a fent említett üzenetközmű problémáit.
Mi az a RocketMQ?
A fenti ábra tipikus üzenetközmű üzenetküldési és fogadási szoftver modellje, a RocketMQ is így van tervezve, röviden: a RocketMQ a következő jellemzőkkel rendelkezik:
- Ez egy sormodell üzenetközmű szoftver, amely nagy teljesítményt, megbízhatóságot, magas valós idejű és elosztott jellemzőket kínál.
- Producer, Consumer és Queue mind terjeszthetők.
- A producer sorban küld üzeneteket néhány sorba sorban, a sorgyűjteményt Topicnak hívják, Consumer If broadcast consumption, egy consumer instance foglalja el az ehhez a témához tartozó összes sort, ha klaszterfogyasztás történik, több fogyasztói példány egyenletesen fogyasztja el a témához tartozó sorgyűjteményt.
- Szigorú üzenetsorrend garantálható
- Gazdag üzenet pull módokat biztosít
- Hatékony vízszintes előfizetői skálázási képességek
- Valós idejű üzenet-előfizetési mechanizmus
- Több százmillió üzenetgyűjtő kapacitás
- Kevesebb függőség
RocketMQ fizikai kinyitási szerkezete
Ahogy a fenti ábrán látható, a RocketMQ telepítési szerkezete a következő jellemzőkkel rendelkezik:
- A Névszerver egy gyakorlatilag állapot nélküli csomópont, amely klaszterekben telepíthető anélkül, hogy információs szinkronizáció lenne a csomópontok között.
- A Broker telepítése viszonylag összetett: a Broker Master és Slave csoportokra oszlik, egy Master több Slave-nek felelhet meg, de a Slave csak egy Masternek felelhet meg, a Master és Slave közötti egyezség ugyanaz BrokerName, más BrokerId megadásával definiálható, BrokerId 0 a Masterre, a non-0 pedig Slave-t jelent. A mestereket többféle módon is be lehet telepíteni. Minden közvetítő hosszú kapcsolatot alakít ki a névszerver klaszter összes csomópontjával, és rendszeres időközönként regisztrálja a témainformációkat az összes névszervernek.
- A producer hosszú kapcsolatot hoz létre a névszerver klaszterének egyik csomópontjával (véletlenszerűen kiválasztva), időszakosan visszanyeri a témaválasztási információkat a Névszervertől, hosszú kapcsolatot alakít ki a témaszolgáltatást nyújtó mesterrel, és rendszeres időközönként küld szívveréseket a mesternek. A producer teljesen állapotmentes, és klaszterekben telepíthető.
- A fogyasztó hosszú kapcsolatot alakít ki a névszerver klaszterének egyik csomópontjával (véletlenszerűen kiválasztva), rendszeresen lekéri a témaválasztási információkat a Névszervertől, és hosszú kapcsolatot alakít ki a Mesterrel és a Szolgalával, akik a témaszolgáltatást nyújtják, és rendszeres időközönként küldi a szívveréseket a Mesternek és a Szolganak. A fogyasztók mind a Master, mind a Slave üzeneteire iratkozhatnak, és az előfizetési szabályokat a Broker konfigurációja határozza meg.
RocketMQ logikai bevetési szerkezete
Ahogy a fenti ábrán látható, a RocketMQ logikai telepítési struktúrája két jellemzővel rendelkezik: Gyártó és Fogyasztó.
Egy üzenetküldő alkalmazás képviseletére használt Producer Group több Producer példányt tartalmaz, amelyek lehetnek több gép, több gép folyamata vagy több Producer objektum egy folyamatban. Egy Producer Group több Topic üzenetet is küldhet, és a Producer Group a következőképpen működik:
- Azonosítani egy gyártótípust
- Az O&M eszközön keresztül lekérdezheted, hogy ebben az üzenetküldő alkalmazásban több Producer példány van-e
- Terjesztési tranzakciós üzenet küldésekor ha a producer váratlanul leáll, a bróker aktívan visszahívja a gyártócsoport bármely gépét, hogy megerősítse a tranzakció státuszát.
Egy fogyasztói üzenetküldő alkalmazás képviseletére használják, és egy fogyasztói csoport több fogyasztói példányt tartalmaz, amelyek lehetnek több gép, több folyamat vagy több fogyasztói objektum egy folyamatban. Egy Fogyasztócsoport több Fogyasztója egyenletesen elosztott módon fogyaszt üzeneteket, és ha sugárzásra állítva állítják be, az adott Fogyasztócsoport minden példánya a teljes adatmennyiséget fogyasztja.
RocketMQ adattároló struktúra
Ahogy a fenti ábrán látható, a RocketMQ olyan tárolási módszert alkalmaz, amely az adatokat az indexektől választja el. Hatékonyan csökkenti a fájlerőforrások, az IO és a memória erőforrások elvesztését. Még olyan hatalmas adatokkal is, mint az Alibaba, a magas párhuzamos forgatókönyvek hatékonyan csökkenthetik a végponttól végpontig tartó késleltetést, és erős vízszintes skálázási képességekkel rendelkeznek.
|
Közzétéve 2017. 07. 28. 20:26:52
|
|
|
|
Közzétéve 2017. 07. 29. 8:09:37