Tämä artikkeli käsittelee ensin, mitä ongelmia viestiväliohjelmiston yleensä täytyy ratkaista, millaisia vaikeuksia näiden ongelmien ratkaisemisessa tulee, voidaanko Apache RocketMQ ratkaista Alibaba korkean suorituskyvyn ja suuren läpimenon hajautetun viestivälitysohjelmiston avoimena lähdekoodina, ja miten nämä ongelmat määritellään määrittelyssä. Tässä artikkelissa esitellään RocketMQ:n arkkitehtuurisuunnittelu, jotta lukijat saavat nopean käsityksen RocketMQ:sta.
1. Mitä ongelmia viestiväliohjelmiston täytyy ratkaista? Julkaise/Tilaa on viestien middleware-toiminnon perustoiminto ja myös verrattuna perinteiseen RPC-viestintään. En mene yksityiskohtiin tässä.
Viestin prioriteettimäärittelyssä kuvattu prioriteetti viittaa viestijonoon, jokaisella viestillä on eri prioriteetti, yleensä kokonaisluvuilla, korkean prioriteetin viesti toimitetaan ensin, jos viesti on kokonaan muistijonossa, se voidaan lajitella ennen toimitusta olevan prioriteetin mukaan, jolloin korkea prioriteetti toimitetaan ensin.
Koska kaikki viestit RocketMQ:ssa ovat pysyviä, jos ne lajitellaan prioriteetin mukaan, ylikuormitus on hyvin suuri, joten RocketMQ ei erityisesti tue viestien prioriteettia, mutta voi toteuttaa vastaavia toimintoja kiertotiedoksi, eli konfiguroida jonon korkealla prioriteetilla ja jonon normaalilla prioriteetilla, ja lähettää eri prioriteetit eri jonoihin.
Prioriteettiasioissa ne voidaan tiivistää kahteen kategoriaan:
- Kunhan prioriteetti saavutetaan, se ei ole tarkasti määritelty prioriteetti, ja prioriteetti jaetaan yleensä korkeaan, keskitasoon, matalaan tai useampaan tasoon. Jokainen prioriteetti voidaan esittää eri aiheena, ja viestiä lähetettäessä määritellään eri aiheet edustamaan prioriteettia, mikä voi ratkaista suurimman osan prioriteettiongelmista, mutta heikentää liiketoiminnan prioriteettien tarkkuutta.
- Tiukka prioriteetti, prioriteetti ilmaistaan kokonaislukuna, kuten 0 ~ 65535, tällainen prioriteettiongelma ei yleensä sovellu ratkaistaviksi eri aiheilla. Jos haluat MQ:n ratkaisevan tämän ongelman, sillä on suuri vaikutus MQ:n suorituskykyyn. Tässä on hyvä varmistaa, että yritys todella tarvitsee tätä tiukkaa priorisointia, ja jos prioriteetit tiivistetään muutamaan, kuinka paljon sillä on vaikutusta liiketoimintaan?
Viestijärjestys viittaa viestityyppiin, joka voidaan käyttää siinä järjestyksessä, jossa se lähetetään. Esimerkiksi tilaus tuottaa kolme viestiä, nimittäin tilauksen luomisen, tilauksen maksun ja tilauksen suorittamisen. Kuluttaessa on merkitystä kuluttaa tässä järjestyksessä. Mutta samalla tilauksia voidaan kuluttaa rinnakkain.
RocketMQ voi varmistaa tarkasti, että viestit ovat järjestelmällisiä.
Message FilterBroker Viestisuodatus
Välittäjässä kuluttajan tarpeiden mukainen suodatus vähentää tarpeettomien viestien välittämistä kuluttajalle.
Haittapuolena on, että se lisää välittäjän taakkaa ja on suhteellisen monimutkainen toteuttaa.
1. Taobao Notify tukee monenlaisia suodatusmenetelmiä, mukaan lukien suora suodatus viestityypin mukaan ja joustava syntaksilausekeiden suodatus, joka voi vastata lähes vaativimpiin suodatustarpeisiin.
2. Taobao RocketMQ tukee suodatusta yksinkertaisella Message Tagilla sekä Message Headerilla ja rungolla.
3. Joustava syntaksilausekeiden suodatus on myös tuettu CORBA Notification -määrittelyssä.
Kuluttajapuolen viestisuodatus
Sovellus voi räätälöidä tämän suodatuksen kokonaan, mutta haittapuolena on, että kuluttajalle lähetetään paljon turhia viestejä.
Viestin pysyvyyteen käytetään useita yleisiä pysyvyysmenetelmiä:
- Säilytä tietokantaan, kuten Mysql.
- Säilytä KV-tallennukseen, kuten levelDB:hen, Berkeley DB:hen ja muihin KV-tallennusjärjestelmiin.
- Pysyvyys tiedostotietueiden muodossa, kuten Kafka, RocketMQ
- Tee pysyvä kuva muistidatasta, kuten beanstalkd, VisiNotify
- (1), (2) ja (3) kaikilla kolmella pysyvyysmenetelmällä on kyky laajentaa muistijonon puskuria, ja (4) ne ovat vain muistikuva, joka voi palauttaa edellisen muistin tiedot sen jälkeen, kun välittäjä lopettaa puhelun ja käynnistyy uudelleen.
JMS- ja CORBA-ilmoitusmäärittelyt eivät määrittele selkeästi, miten se säilytetään, mutta pysyvyysosan suorituskyky määrittää suoraan koko viestiväliohjelman suorituskyvyn.
RocketMQ hyödyntää täysimääräisesti Linuxin tiedostojärjestelmän muistivälimuistia suorituskyvyn parantamiseksi.
On useita tilanteita, joissa viestin luotettavuus vaikuttaa viestin luotettavuuteen:
- Välittäjä sulkee normaalisti
- Välittäjän romahdus
- Käyttöjärjestelmän kaatuminen
- Kone menettää virran, mutta virtalähde voidaan palauttaa välittömästi.
- Kone ei käynnisty (se voi olla vaurioitunut keskeisille laitteille, kuten prosessorille, emolevylle, muistille jne.)
- Levylaitteen vaurio.
(1), (2), (3) ja (4) ovat kaikki tilanteita, joissa laitteistoresurssit voidaan palauttaa välittömästi, ja RocketMQ voi varmistaa, ettei viestejä katoa tai että pieni määrä dataa menety (riippuen siitä, onko flashausmenetelmä synkroninen vai asynkroninen).
(5) (6) Kyseessä on yksittäinen vikaantumispiste eikä sitä voi palauttaa, sillä kun se tapahtuu, kaikki viestit tällä yksittäisellä pisteellä katoavat. Molemmissa tapauksissa RocketMQ varmistaa, että 99 % viesteistä ei katoa asynkronisen replikaation kautta, mutta silti hyvin vähän viestejä voi kadota. Synkroninen kaksoiskirjoitusteknologia voi täysin välttää yksittäiset pisteet, mikä väistämättä heikentää suorituskykyä, tehden siitä sopivan erittäin korkeiden viestien luotettavuusvaatimusten vaatimuksiin, kuten rahaan liittyviin sovelluksiin.
RocketMQ tukee synkronista kaksoiskirjoitusta versiosta 3.0 alkaen.
Matalaviiveinen viestintä voi tavoittaa kuluttajan välittömästi viestin saavuttua välittäjän ilman viestien kertymistä.
RocketMQ käyttää pitkää kyselyhakumenetelmää varmistaakseen, että viesti on hyvin reaaliaikainen, eikä reaaliaikainen viesti ole alempi kuin push-viesti.
Vähintään kerran tarkoittaa, että jokainen viesti on toimitettava kerran.
RocketMQ Consumer hakee ensin viestin paikalliselle alueelle ja palauttaa ackin palvelimelle kulutuksen jälkeen.
Täsmälleen vain kerran- Viestin lähettämisvaihe ei salli päällekkäisten viestien lähettämistä.
- Consume Message -vaiheessa kaksoisviestejä ei saa kuluttaa.
Vasta kun yllä mainitut kaksi ehtoa täyttyvät, viestiä voidaan pitää "Täsmälleen vain kerran", ja näiden kahden tavoitteen saavuttamiseksi hajautetussa järjestelmäympäristössä syntyy väistämättä valtavaa ylikuormaa. Siksi korkean suorituskyvyn saavuttamiseksi RocketMQ ei takaa tätä ominaisuutta ja vaatii liiketoiminnassa duplikointia, mikä tarkoittaa, että kuluttajaviestien on oltava idempotentteja. Vaikka RocketMQ ei voi tiukasti taata päällekkäisyyksien välttämistä, normaalisti lähetyksiä ja kulutusta tapahtuu harvoin, vain verkon poikkeavuuksia, kuluttajan käynnistystä ja pysäyttämistä sekä muita poikkeavia tilanteita, kuten viestien kopiointia.
Tämän ongelman keskeinen syy on epävarmuus verkkopuheluissa, eli kolmas tila, jossa ei onnistu eikä epäonnistu, joten viestin toiston ongelma syntyy.
Mitä minun pitäisi tehdä, jos välittäjän puskuri on täynnä? Välittäjän puskuri viittaa yleensä välittäjän jonon muistipuskurin kokoon, joka on yleensä rajoitettu – entä jos puskuri on täynnä?
Näin asia käsitellään CORBA-ilmoitusmäärityksessä:
- RejectNewEvents hylkää uuden viestin ja palauttaa RejectNewEvents-virhekoodin tuottajalle.
- Hylkää olemassa olevat viestit tietyn käytännön mukaisesti
- AnyOrder – Mikä tahansa tapahtuma voidaan hylätä ylivuodon yhteydessä. Tämä on tämän ominaisuuden oletusasetus.
- FifoOrder – Ensimmäinen vastaanotettu tapahtuma hylätään.
- LifoOrder – Viimeinen vastaanotettu tapahtuma hylätään ensimmäisenä.
- Prioriteettijärjestys – Tapahtumat tulee hylätä prioriteettijärjestyksessä, jotta matalamman prioriteetin tapahtumat hylätään ennen korkeamman prioriteetin tapahtumia.
- DeadlineOrder – Tapahtumat tulee hylätä lyhyimmän määräajan mukaisessa järjestyksessä ensin.
RocketMQ:lla ei ole muistipuskurin käsitettä, ja RocketMQ:n jonot ovat pysyviä levyjä, ja data tyhjennetään säännöllisesti.
Tämän ongelman ratkaisemiseksi RocketMQ:lla on hyvin merkittävä ero muihin MQ:ihin verrattuna: RocketMQ:n muistipuskuri on abstrahoittu äärettömäksi jonoksi, riippumatta siitä, kuinka paljon dataa tulee sisään, se voidaan asentaa, tämä äärettömyys perustuu siihen, välittäjä poistaa säännöllisesti vanhentuneita tietoja, esimerkiksi välittäjä tallentaa vain 3 päivän viestipäivää, jolloin vaikka tämän puskurin pituus on ääretön, 3 päivän takaiset tiedot poistetaan jonon lopusta.
Retrospektiivinen kulutus tarkoittaa viestiä, jonka kuluttaja on onnistuneesti kuluttanut, ja viesti täytyy kuluttaa uudelleen liiketoiminnan kysynnän vuoksi. Esimerkiksi kuluttajajärjestelmän epäonnistumisen vuoksi tunnin takainen data täytyy käyttää uudelleen palautuksen jälkeen, jolloin välittäjän tulisi tarjota mekanismi kulutuskulutuksen palauttamiseksi aikadimension mukaan.
RocketMQ tukee ajan perusteella retrospektiivistä kulutusta, jonka aikadimensio on tarkka millisekunteihin ja jota voidaan palauttaa eteen- tai taaksepäin.
Viestipinouksen viestiväliohjelmiston päätehtävä on asynkroninen irrottaminen, ja toinen tärkeä toiminto on estää etupään datatulvahuippu ja varmistaa taustajärjestelmän vakaus, mikä vaatii viestiväliohjelmistolta tietyn viestipinoutumiskyvyn, ja viestikeno integroi seuraavat kaksi tilannetta:
- Viestit kasataan muistipuskureihin, ja kun ne ylittävät muistipuskurin, viestejä voidaan pudottaa tietyn pudotuskäytännön mukaisesti, kuten CORBA Notification -määrittelyssä kuvataan. Se soveltuu palveluille, jotka kestävät viestien hylkäämisen; tässä tapauksessa viestien kertymiskapasiteetti johtuu pääasiassa muistipuskurin koosta, eikä suorituskyvyn heikkeneminen ole liian suuri viestin pinoamisen jälkeen, koska muistin datamäärä vaikuttaa rajallisesti ulkomaailmalle tarjottuun pääsyyn.
- Viestit kasaantuvat pysyviin tallennusjärjestelmiin, kuten tietokantaan, KV-tallennukseen ja tiedostotietuelomakkeeseen. Kun viestejä ei voi osua muistivälimuistiin, on väistämätöntä päästä levylle, mikä tuottaa suuren määrän luku-IO:ta, ja luku-IO:n läpäisykyky määrittää suoraan viestien pääsyn niiden kasaantumisen jälkeen.
Viestien kertymiskyvyn arviointiin on neljä pääasiaa:
- Kuinka monta viestiä voi kasata, kuinka monta tavua? Eli viestin valtava kapasiteetti.
- Kun viesti on kasattu, vaikuttaako viestin läpimenoon pinoaminen?
- Vaikuttaako kuluttajien normaali kulutus, kun viesti kasaantuu?
- Kun viestit on kasattu, mikä on läpimeno, kun pääsee käsiksi levylle kasaantuneisiin viesteihin?
Hajautetut transaktiot Useita tunnettuja hajautetun transaktion määrittelyjä, kuten XA, JTA jne. Näistä XA-määrittelyä tukevat laajasti suuret tietokantatoimittajat, kuten Oracle, Mysql jne. Näistä XA:n TM-toteutuksen johtaja, kuten Oracle Tuxedo, on laajasti käytössä rahoituksessa, telekommunikaatiossa ja muilla aloilla.
Hajautetuissa transaktioissa on kaksivaiheisia commit-ongelmia, ja datan tallennuksen osalta KV-tallennusta on tuettava, koska commit-rollbackin toinen vaihe tarvitsee viestin tilaa, johon kuuluu viestin löytäminen avaimen mukaan. RocketMQ ohittaa ongelman viestin löytämisessä avaimen mukaan toisessa vaiheessa, käyttää ensimmäistä vaihetta valmistellun viestin lähettämiseen, viestin offsetin saamista, ja toista vaihetta viestin käsittelyyn offsetin kautta ja tilan muokkaamiseen; siirtymä on datan osoite.
RocketMQ:n transaktioiden toteutusmenetelmä ei tapahdu KV-tallennuksen kautta, vaan offset-menetelmällä, jossa on merkittävä puute: datan muuttaminen offsetin kautta aiheuttaa liikaa likaisia sivuja järjestelmään, mikä vaatii erityistä huomiota.
Aikataulutetut viestit Aikataulutetut viestit tarkoittavat, että kuluttajat eivät voi käyttää viestejä heti välittäjälle lähettämisen jälkeen, vaan ne voidaan käyttää vain tiettynä ajankohtana tai tietyn ajan odottamisen jälkeen.
Jos haluat tukea mielivaltaista aikatarkkuutta, välittäjätasolla sinun täytyy tehdä viestien lajittelua, ja jos kyse on pysyvyydestä, viestien lajittelu aiheuttaa väistämättä valtavan suorituskyvyn ylikuormituksen.
RocketMQ tukee ajoitusviestejä, mutta ei mielivaltaista aikatarkkuutta, ja tukee tiettyjä tasoja, kuten ajoitusta 5s, 10s, 1m jne.
Viestin uudelleenyritys Kun kuluttaja ei kuluta viestiä, tarjoa uudelleenyritysmekanismi, joka saa viestin kuluttamaan uudelleen. Kuluttajaviestien epäonnistumiset voidaan yleensä tarkastella seuraavissa tilanteissa:
- Viestin syyn vuoksi, kuten deserialisaation epäonnistuminen, viestitietoja ei voida käsitellä (kuten puhelinlaskun lataus, nykyisen viestin matkapuhelinnumero on kirjautunut ulos, sitä ei voi ladata) jne. Tämä virhe vaatii yleensä tämän viestin ohittamista ja muiden viestien kuluttamista, ja epäonnistunut viesti epäonnistuu 99 %, vaikka käyttö kokeiltaisiin uudelleen heti, joten on parasta tarjota ajoitettu uudelleenyritys, eli yrittää uudelleen 10 sekunnin jälkeen.
- Koska riippuvaiset alavirran sovelluspalvelut eivät ole saatavilla, kuten tietokantayhteys ei ole käytettävissä, ulkoinen järjestelmäverkko on saavuttamattomissa jne. Tämän virheen kohdatessa, vaikka nykyinen epäonnistunut viesti ohitettaisiin, myös muita viestejä kulutetaan. Tässä tapauksessa suositellaan laittamaan lepo-30 sekuntia ja seuraamaan seuraavaa viestiä, mikä voi vähentää välittäjän painetta yrittää viestiä uudelleen.
RocketMQ:n yleiskatsaus Selviää, ratkaiseeko RocketMQ edellä mainitun viestivälivarren ongelmat.
Mikä on RocketMQ?
Yllä oleva kuva on tyypillinen viestiväliohjelmistomalli, joka lähettää ja vastaanottaa viestejä, RocketMQ on myös suunniteltu näin, lyhyesti sanottuna RocketMQ:lla on seuraavat ominaisuudet:
- Se on jonomallin viestiväliohjelmisto, jolla on korkea suorituskyky, korkea luotettavuus, korkea reaaliaikaisuus ja hajautetut ominaisuudet.
- Tuottaja, kuluttaja ja jono voidaan kaikki jakaa.
- Tuottaja lähettää vuorotellen viestejä joillekin jonoille, jonokokoelmaa kutsutaan nimellä Topic, Consumer If broadcast consumption, yksi kuluttaja-instanssi kuluttaa kaikki tämän aiheen mukaiset jonot, ja jos käytetään klusterikulutusta, useat kuluttaja-instanssit kuluttavat tätä aihetta vastaavan jonokokoelman tasaisesti.
- Tiukka viestijärjestys voidaan taata
- Tarjoaa rich message pull -tilat
- Tehokkaat vaakasuorat tilaajan skaalausmahdollisuudet
- Reaaliaikainen viestien tilausmekanismi
- Satojen miljoonien viestien kertymiskapasiteetti
- Vähemmän riippuvuutta
RocketMQ:n fyysinen laukaisurakenne
Kuten yllä olevassa kuvassa näkyy, RocketMQ:n laukaisurakenne sisältää seuraavat ominaisuudet:
- Name Server on käytännössä tilaton solmu, joka voidaan ottaa käyttöön klustereissa ilman tiedon synkronointia solmujen välillä.
- Välittäjän käyttöönotto on suhteellisen monimutkainen: välittäjä on jaettu mestariin ja orjaan, mestari voi vastata useita orjia, mutta orja voi vastata vain yhtä mestaria, isännän ja orjan välinen vastaavuus määritellään määrittämällä sama välittäjänimi, eri välittäjä, välittäjä on 0 mestarille ja ei-0 tarkoittaa orjaa. Mastereita voidaan myös käyttää useampana. Jokainen välittäjä muodostaa pitkän yhteyden kaikkiin nimipalvelinklusterin solmuihin ja rekisteröi aihetiedot kaikille nimipalvelimille säännöllisin väliajoin.
- Tuottaja muodostaa pitkän yhteyden johonkin nimipalvelinklusterin solmuista (satunnaisesti valittu), hakee säännöllisesti aiheiden reititystietoa nimipalvelimelta, muodostaa pitkän yhteyden masteriin, joka tarjoaa aihepalvelun, ja lähettää sydämenlyönnit masterille säännöllisin väliajoin. Tuottaja on täysin tilaton ja voidaan ottaa käyttöön klustereissa.
- Kuluttaja muodostaa pitkän yhteyden johonkin nimipalvelinklusterin solmuun (satunnaisesti valittu), hakee säännöllisesti aiheiden reititystietoa nimipalvelimelta ja muodostaa pitkän yhteyden Masteriin ja Slaveen, jotka tarjoavat aihepalvelun, ja lähettää sydämenlyönnit Masterille ja Slavelle säännöllisin väliajoin. Kuluttajat voivat tilata viestejä sekä Masterilta että Slavelta, ja tilaussäännöt määräytyvät välittäjän konfiguraatiosta.
RocketMQ:n looginen laukaisurakenne
Kuten yllä olevassa kuvassa näkyy, RocketMQ:n loogisella käyttöönottorakenteella on kaksi ominaisuutta: tuottaja ja kuluttaja.
Viestisovelluksen esittämiseen käytetty Tuottajaryhmä sisältää useita Tuottaja-instansseja, jotka voivat olla useita koneita, useita koneen prosesseja tai useita Tuottaja-objekteja. Tuottajaryhmä voi lähettää useita aiheviestejä, ja tuottajaryhmä toimii seuraavasti:
- Tunnista tuottajatyyppi
- Voit tiedustella, että tässä viestisovelluksessa on useita tuottaja-instansseja O&M-työkalun avulla
- Kun hajautettu tapahtumaviesti lähetetään, jos tuottaja menee yllättäen alas, välittäjä soittaa aktiivisesti takaisin mille tahansa tuottajaryhmän koneelle vahvistaakseen tapahtumatilan.
Kuluttajaviestisovelluksen edustamiseen käytetty kuluttajaryhmä sisältää useita kuluttajainstansseja, jotka voivat olla useita koneita, useita prosesseja tai useita kuluttajaobjekteja samassa prosessissa. Useat kuluttajat kuluttajaryhmässä kuluttavat viestejä tasaisesti jaetusti, ja jos ne on asetettu lähettämään, jokainen instanssi tämän kuluttajaryhmän alaisuudessa kuluttaa koko datamäärän.
RocketMQ:n datan tallennusrakenne
Kuten yllä olevassa kuvassa näkyy, RocketMQ käyttää tallennusmenetelmää, joka erottaa datan indekseistä. Tehokkaasti vähennetään tiedostoresurssien, IO-resurssien ja muistiresurssien menetystä. Vaikka käytössä olisi valtava data, kuten Alibaba, korkean rinnakkaisuuden skenaariot voivat tehokkaasti vähentää viivettä päästä päähän ja tarjota vahvat vaakasuuntaiset skaalausmahdollisuudet.
|
Julkaistu 28.7.2017 20.26.52
|
|
|
|
Julkaistu 29.7.2017 8.09.37