Šis raksts vispirms noved pie tā, kādas problēmas ziņojumu starpprogrammatūra parasti ir jāatrisina, kādas grūtības radīsies šo problēmu risināšanā, vai Apache RocketMQ var atrisināt kā augstas veiktspējas, augstas caurlaidības izplatītu ziņojumu starpprogrammatūru Alibaba atvērtajā kodā un kā šīs problēmas ir definētas specifikācijā. Pēc tam šajā rakstā tiks iepazīstināts ar RocketMQ arhitektūras dizainu, lai lasītāji ātri izprastu RocketMQ.
1. Kādas problēmas jāatrisina ziņojumu starpprogrammatūrai? Publicēt/abonēt ir visvienkāršākā ziņojumu starpprogrammatūras funkcija, un tā ir arī saistīta ar tradicionālo RPC komunikāciju. Es šeit neiedziļināšos detaļās.
Ziņojuma prioritātes specifikācijā aprakstītā prioritāte attiecas uz ziņojumu rindu, katram ziņojumam ir atšķirīga prioritāte, ko parasti apraksta veseli skaitļi, ziņojums ar augstu prioritāti tiek piegādāts vispirms, ja ziņojums ir pilnībā atmiņas rindā, tad to var sakārtot pēc prioritātes pirms piegādes, lai vispirms tiktu piegādāta augsta prioritāte.
Tā kā visi RocketMQ ziņojumi ir noturīgi, ja tie tiek sakārtoti pēc prioritātes, pieskaitāmās izmaksas būs ļoti lielas, tāpēc RocketMQ īpaši neatbalsta ziņojumu prioritāti, bet var īstenot līdzīgas funkcijas risinājumā, tas ir, konfigurēt rindu ar augstu prioritāti un rindu ar normālu prioritāti un nosūtīt dažādas prioritātes dažādām rindām.
Prioritārajiem jautājumiem tos var apkopot 2 kategorijās:
- Kamēr prioritāte ir sasniegta, tā nav prioritāte tiešā nozīmē, un prioritāte parasti tiek sadalīta augstos, vidējos, zemos vai vairākos līmeņos. Katru prioritāti var attēlot ar citu tēmu, un, nosūtot ziņojumu, norādiet dažādas tēmas, kas atspoguļo prioritāti, kas var atrisināt lielāko daļu prioritāro problēmu, bet apdraudēt biznesa prioritāšu precizitāti.
- Stingra prioritāte, prioritāte tiek izteikta kā vesels skaitlis, piemēram, 0 ~ 65535, šāda veida prioritārā problēma parasti nav piemērota risināšanai ar dažādām tēmām. Ja vēlaties, lai MQ atrisinātu šo problēmu, tam būs ļoti liela ietekme uz MQ veiktspēju. Šeit ir punkts, lai pārliecinātos, ka uzņēmumam patiešām ir nepieciešama šī stingra prioritāšu noteikšana, un, ja prioritātes ir saspiestas dažās daļās, cik liela ietekme tam būs uz biznesu?
Ziņojumu secība attiecas uz ziņojuma tipu, ko var patērēt tādā secībā, kādā tas tiek nosūtīts. Piemēram, pasūtījums ģenerē 3 ziņojumus, proti, pasūtījuma izveidi, pasūtījuma apmaksu un pasūtījuma pabeigšanu. Patērējot, ir jēga patērēt šādā secībā. Bet tajā pašā laikā pasūtījumus var patērēt paralēli.
RocketMQ var stingri nodrošināt, ka ziņojumi ir sakārtoti.
Ziņojumu filtrsBroker ziņojumu filtrēšana
Brokerī filtrēšana atbilstoši patērētāja prasībām samazina nevajadzīgu ziņojumu pārsūtīšanu patērētājam.
Trūkums ir tas, ka tas palielina brokera slogu un ir salīdzinoši sarežģīti īstenojams.
1. Taobao Notify atbalsta dažādas filtrēšanas metodes, tostarp tiešo filtrēšanu pēc ziņojuma veida un elastīgu sintakses izteiksmju filtrēšanu, kas var apmierināt gandrīz visprasīgākās filtrēšanas vajadzības.
2. Taobao RocketMQ atbalsta filtrēšanu pēc vienkārša ziņojuma taga, kā arī ziņojuma galvenes un pamatteksta.
3. Elastīga sintakses izteiksmju filtrēšana tiek atbalstīta arī CORBA paziņojuma specifikācijā.
Patērētāja puses ziņojumu filtrēšana
Šo filtrēšanu lietojumprogramma var pilnībā pielāgot, taču negatīvie ir tas, ka patērētājam tiek nosūtīti daudz bezjēdzīgu ziņojumu.
Ir vairākas izplatītas noturības metodes, ko izmanto ziņojuma noturībai:
- Saglabājiet datu bāzi, piemēram, Mysql.
- Saglabājiet KV krātuvi, piemēram, levelDB, Berkeley DB un citas KV krātuves sistēmas.
- Noturība failu ierakstu veidā, piemēram, Kafka, RocketMQ
- Izveidojiet pastāvīgu atmiņas datu attēlu, piemēram, beanstalkd, VisiNotify
- (1), (2) un (3) visām trim noturības metodēm ir iespēja paplašināt atmiņas rindas buferi, un (4) ir tikai atmiņas attēls, kas joprojām var atjaunot datus no iepriekšējās atmiņas pēc brokera uzkarināšanas un restartēšanas.
JMS un CORBA paziņojumu specifikācijās nav skaidri norādīts, kā saglabāt, bet noturības daļas veiktspēja tieši nosaka visas ziņojuma starpprogrammatūras veiktspēju.
RocketMQ pilnībā izmanto Linux failu sistēmas atmiņas kešatmiņu, lai uzlabotu veiktspēju.
Ir vairākas situācijas, kurās ziņojumu uzticamība ietekmē ziņojumu uzticamību:
- Brokeris aizveras normāli
- Brokera avārija
- OS avārija
- Mašīna zaudē jaudu, bet strāvas padevi var atjaunot nekavējoties.
- Ierīce neieslēdzas (tā var būt bojāta galvenajām ierīcēm, piemēram, CPU, mātesplatei, atmiņai utt.)
- Diska ierīces bojājumi.
(1), (2), (3) un (4) ir situācijas, kad aparatūras resursus var atgūt nekavējoties, un RocketMQ var nodrošināt, ka ziņojumi netiek zaudēti vai tiek zaudēts neliels datu apjoms (atkarībā no tā, vai mirgošanas metode ir sinhrona vai asinhrona).
(5) (6) Tas ir viens kļūmes punkts, un to nevar atgūt, tiklīdz tas notiek, visi ziņojumi par šo punktu tiek zaudēti. Abos gadījumos RocketMQ nodrošina, ka 99% ziņojumu netiek zaudēti, izmantojot asinhronu replicēšanu, taču joprojām ir ļoti maz ziņojumu, kas var tikt zaudēti. Sinhronā dubultās rakstīšanas tehnoloģija var pilnībā izvairīties no atsevišķiem punktiem, kas neizbēgami ietekmēs veiktspēju, padarot to piemērotu situācijām ar ārkārtīgi augstām ziņojumu uzticamības prasībām, piemēram, ar naudu saistītām lietojumprogrammām.
RocketMQ atbalsta sinhronu dubultu rakstīšanu, sākot no versijas 3.0.
Zema latentuma ziņojumapmaiņa var sasniegt patērētāju tūlīt pēc tam, kad ziņojums sasniedz brokeri, neuzkrājot ziņojumus.
RocketMQ izmanto garu aptaujas vilkšanas metodi, lai nodrošinātu, ka ziņojums ir ļoti reāllaiks, un reāllaika ziņojums nav zemāks par push.
Vismaz vienu reizi nozīmē, ka katrs ziņojums ir jāpiegādā vienu reizi.
RocketMQ Consumer vispirms izvelk ziņojumu uz vietējo apgabalu un pēc tam pēc patēriņa pabeigšanas atgriež ack serverī.
Tieši tikai vienu reizi- Ziņojuma nosūtīšanas posms neļauj sūtīt ziņojumu dublikātus.
- Posmā Ziņojuma patērēšana nav atļauts lietot ziņojumu dublikātus.
Tikai tad, ja ir izpildīti divi iepriekš minētie nosacījumi, ziņojumu var uzskatīt par "Tieši tikai vienu reizi", un, lai sasniegtu iepriekš minētos divus punktus, izkliedētajā sistēmas vidē neizbēgami radīsies milzīgas pieskaitāmās izmaksas. Tāpēc, lai sasniegtu augstu veiktspēju, RocketMQ negarantē šo funkciju un prasa deduplikāciju biznesā, kas nozīmē, ka patērētāju ziņojumiem jābūt idempotentiem. Lai gan RocketMQ nevar stingri garantēt nedublēšanos, normālos apstākļos reti notiek atkārtota sūtīšana un patēriņš, tikai tīkla novirzes, patērētāju palaišana un apturēšana un citas neparastas situācijas, piemēram, ziņojumu dublēšana.
Šīs problēmas galvenais iemesls ir tas, ka tīkla zvanos ir nenoteiktība, tas ir, trešais stāvoklis, kurā nav ne panākumu, ne neveiksmes, tāpēc rodas ziņojumu atkārtošanās problēma.
Kas man jādara, ja brokera buferis ir pilns? Brokera buferis parasti attiecas uz brokera rindas atmiņas bufera lielumu, kas parasti ir ierobežots, ko darīt, ja buferis ir pilns?
Lūk, kā tas tiek apstrādāts CORBA paziņojuma specifikācijā:
- RejectNewEvents noraida jauno ziņojumu un atgriež producentam kļūdas kodu RejectNewEvents.
- Atmest esošos ziņojumus saskaņā ar noteiktu politiku
- AnyOrder - Jebkurš notikums var tikt atmests pēc pārplūdes. Šis ir šī rekvizīta noklusējuma iestatījums.
- FifoOrder - pirmais saņemtais notikums būs pirmais, kas tiks izmests.
- LifoOrder - Pēdējais saņemtais notikums būs pirmais izmestais.
- PriorityOrder — notikumi ir jāatmet prioritārā secībā, lai zemākas prioritātes notikumi tiktu atmesti pirms augstākas prioritātes notikumiem.
- DeadlineOrder - Notikumi vispirms jāizmet īsākā termiņa secībā.
RocketMQ nav atmiņas bufera jēdziena, un RocketMQ rindas ir pastāvīgi diski, un dati tiek regulāri notīrīti.
Šīs problēmas risināšanai RocketMQ ir ļoti būtiska atšķirība no citiem MQ, RocketMQ atmiņas buferis tiek abstrahēts bezgalīga garuma rindā, neatkarīgi no tā, cik daudz datu ienāk, to var instalēt, šī bezgalība ir priekšnoteikums, brokeris regulāri izdzēsīs datus, kuriem beidzies derīguma termiņš, piemēram, brokeris saglabā tikai 3 dienu ziņojumus, tad, lai gan šī bufera garums ir bezgalīgs, bet dati pirms 3 dienām tiks izdzēsti no rindas beigām.
Retrospektīvs patēriņš attiecas uz ziņojumu, ka patērētājs ir veiksmīgi patērējis, un ziņojums ir jāpatērē atkārtoti biznesa pieprasījuma dēļ. Piemēram, patērētāju sistēmas kļūmes dēļ dati pirms 1 stundas ir jāpatērē atkārtoti pēc atgūšanas, tad brokerim jānodrošina mehānisms, lai atgrieztu patēriņa progresu atbilstoši laika dimensijai.
RocketMQ atbalsta retrospektīvu patēriņu, pamatojoties uz laiku, ar laika dimensiju, kas ir precīza milisekundēs, ko var atgriezt uz priekšu vai atpakaļ.
Ziņojumu kraušanas ziņojumu starpprogrammatūras galvenā funkcija ir asinhrona atsaistīšana, un vēl viena svarīga funkcija ir bloķēt priekšgala datu plūdu maksimumu un nodrošināt aizmugures sistēmas stabilitāti, kas prasa, lai ziņojumu starpprogrammatūrai būtu noteikta ziņojumu kraušanas spēja, un ziņojumu kaudze integrē šādas divas situācijas:
- Ziņojumi tiek uzkrāti atmiņas buferos, un, kad tie pārsniedz atmiņas buferi, ziņojumus var nomest saskaņā ar noteiktu nomešanas politiku, kā aprakstīts CORBA paziņojumu specifikācijā. Tas ir piemērots pakalpojumiem, kas var paciest ziņojumu izmešanu, šajā gadījumā ziņojumu uzkrāšanās jauda galvenokārt ir atmiņas bufera lielums, un veiktspējas pasliktināšanās nebūs pārāk liela pēc ziņojuma sakraušanas, jo atmiņā esošo datu apjomam ir ierobežota ietekme uz piekļuves iespējām, kas tiek nodrošinātas ārpasaulei.
- Ziņojumi tiek uzkrāti pastāvīgās atmiņas sistēmās, piemēram, DB, KV krātuvē, failu ierakstu formā. Ja ziņojumus nevar sasniegt atmiņas kešatmiņā, ir neizbēgami piekļūt diskam, kas radīs lielu daudzumu lasīta IO, un lasītā IO caurlaidspēja tieši nosaka ziņojumu piekļuves spēju pēc to uzkrāšanas.
Ir četri galvenie punkti, lai novērtētu ziņojumu uzkrāšanas spēju:
- Cik ziņojumu var uzkrāt, cik baitu? Tas ir, ziņojuma kaudzes ietilpība.
- Vai pēc ziņojuma uzkrāšanas ziņojuma caurlaidspēju ietekmē kraušana?
- Vai pēc ziņu uzkrāšanās tiks ietekmēts patērētāju normālais patēriņš?
- Pēc ziņojumu sakrāšanas, kāda ir caurlaidspēja, piekļūstot ziņojumiem, kas uzkrāti diskā?
Izplatītie darījumi Vairākas zināmas izplatīto darījumu specifikācijas, piemēram, XA, JTA utt. Starp tiem XA specifikāciju plaši atbalsta lielākie datu bāzu pārdevēji, piemēram, Oracle, MySQL utt. Starp tiem XA TM ieviešanas līderis, piemēram, Oracle Tuxedo, tiek plaši izmantots finanšu, telekomunikāciju un citās jomās.
Izplatītie darījumi ietver divpakāpju saistību problēmas, un datu glabāšanas ziņā ir jāatbalsta KV krātuve, jo otrajā izpildes atcelšanas posmā ir jāmaina ziņojuma stāvoklis, kas ietver ziņojuma atrašanu saskaņā ar atslēgu. RocketMQ apiet problēmu, kas saistīta ar ziņojuma atrašanu saskaņā ar atslēgu otrajā posmā, izmantojot pirmo posmu, lai nosūtītu sagatavoto ziņojumu, iegūtu ziņojuma nobīdi, un otro posmu, lai piekļūtu ziņojumam, izmantojot nobīdi un modificētu stāvokli, nobīde ir datu adrese.
RocketMQ darījumu ieviešanas metode netiek veikta, izmantojot KV krātuvi, bet gan ar kompensācijas metodi, kurai ir ievērojams trūkums, tas ir, datu maiņa, izmantojot nobīdi, radīs pārāk daudz netīru lapu sistēmā, kam nepieciešama īpaša uzmanība.
Plānotie ziņojumi Plānotie ziņojumi nozīmē, ka patērētāji nevar patērēt ziņojumus uzreiz pēc to nosūtīšanas brokerim, un tos var patērēt tikai noteiktā laika posmā vai pēc konkrēta laika gaidīšanas.
Ja vēlaties atbalstīt patvaļīgu laika precizitāti, brokera līmenī jums ir jāveic ziņojumu kārtošana, un, ja ir iesaistīta neatlaidība, tad ziņojumu kārtošana neizbēgami radīs milzīgas veiktspējas pieskaitāmās izmaksas.
RocketMQ atbalsta laika ziņojumus, bet neatbalsta patvaļīgu laika precizitāti un atbalsta noteiktus līmeņus, piemēram, 5s, 10s, 1m utt.
Ziņojuma atkārtota mēģināšana Pēc tam, kad patērētājs neizdodas patērēt ziņojumu, nodrošiniet atkārtotas mēģināšanas mehānismu, lai ziņojums tiktu patērēts vēlreiz. Patērētāju patēriņa ziņojumu kļūmes parasti var uzskatīt šādās situācijās:
- Paša ziņojuma iemesla dēļ, piemēram, deserializācijas kļūme, pašus ziņojuma datus nevar apstrādāt (piemēram, tālruņa rēķina uzlāde, pašreizējā ziņojuma mobilā tālruņa numurs ir izrakstīts, to nevar uzlādēt) utt. Šī kļūda parasti prasa izlaist šo ziņojumu un patērēt citus ziņojumus, un šis neveiksmīgais ziņojums ir 99% neveiksmīgs pat tad, ja patēriņš tiek mēģināts atkārtoti nekavējoties, tāpēc vislabāk ir nodrošināt laika atkārtošanas mehānismu, tas ir, mēģiniet atkārtoti pēc 10 sekundēm.
- Tā kā atkarīgie pakārtotie lietojumprogrammu pakalpojumi nav pieejami, piemēram, DB savienojums nav pieejams, ārējais sistēmas tīkls nav sasniedzams utt. Ja rodas šī kļūda, pat ja pašreizējais neveiksmīgais ziņojums tiek izlaists, tiks patērēti arī citi ziņojumi. Šajā gadījumā ieteicams lietot miegu 30s un patērēt nākamo ziņojumu, kas var samazināt spiedienu uz brokeri atkārtoti mēģināt ziņojumu.
RocketMQ pārskatsUzzināsim, vai RocketMQ atrisina problēmas, ar kurām saskaras iepriekš minētā ziņojuma starpprogrammatūra.
Kas ir RocketMQ?
Iepriekš minētais attēls ir tipisks ziņojumu starpprogrammatūras sūtīšanas un saņemšanas modelis, RocketMQ ir izstrādāts arī šādā veidā, īsāk sakot, RocketMQ ir šādas īpašības:
- Tā ir rindas modeļa ziņojumu starpprogrammatūra ar augstu veiktspēju, augstu uzticamību, augstu reāllaiku un izplatītām īpašībām.
- Ražotājs, patērētājs un rinda var tikt izplatīti.
- Producents pēc kārtas nosūta ziņojumus dažām rindām, rindu kolekciju sauc par tēmu, patērētājs Ja apraides patēriņš, viena patērētāja instance patērē visas rindas, kas atbilst šai tēmai, un, ja klastera patēriņš, vairākas patērētāju instances vienmērīgi patērē rindu kolekciju, kas atbilst šai tēmai.
- Var garantēt stingru ziņojumu secību
- Nodrošina bagātīgus ziņojumu vilkšanas režīmus
- Efektīvas horizontālās abonentu mērogošanas iespējas
- Reāllaika ziņojumu abonēšanas mehānisms
- Simtiem miljonu ziņojumu uzkrāšanas jauda
- Mazāka atkarība
RocketMQ fiziskās izvietošanas struktūra
Kā parādīts iepriekš redzamajā attēlā, RocketMQ izvietošanas struktūrai ir šādas īpašības:
- Nosaukumu serveris ir praktiski bezstāvokļa mezgls, ko var izvietot klasteros bez informācijas sinhronizācijas starp mezgliem.
- Brokera izvietošana ir salīdzinoši sarežģīta, Broker ir sadalīts Master un Slave, Master var atbilst vairākiem Slaves, bet Slave var atbilst tikai vienam Master, atbilstība starp Master un Slave tiek definēta, norādot to pašu BrokerName, atšķirīgu BrokerId, BrokerId ir 0 Master un ne-0 nozīmē Slave. Meistarus var izvietot arī vairākos. Katrs brokeris izveido ilgstošu savienojumu ar visiem nosaukumu servera klastera mezgliem un regulāri reģistrē tēmas informāciju visiem nosaukumu serveriem.
- Producents izveido garu savienojumu ar vienu no nosaukumu servera klastera mezgliem (nejauši izvēlēts), periodiski izgūst tēmu maršrutēšanas informāciju no nosaukumu servera, izveido garu savienojumu ar meistaru, kas nodrošina tēmas pakalpojumu, un regulāri nosūta sirdspukstus kapteinim. Producents ir pilnīgi bezvalstnieks un to var izvietot klasteros.
- Patērētājs izveido garu savienojumu ar vienu no nosaukumu servera klastera mezgliem (nejauši izvēlēts), regulāri izgūst tēmu maršrutēšanas informāciju no nosaukumu servera un izveido garu savienojumu ar Master un Slave, kas nodrošina tēmas pakalpojumu, un regulāri nosūta sirdspukstus Master un Slave. Patērētāji var abonēt ziņojumus gan no Master, gan Slave, un abonēšanas noteikumus nosaka Broker konfigurācija.
RocketMQ loģiskā izvietošanas struktūra
Kā parādīts iepriekš redzamajā attēlā, RocketMQ loģiskajai izvietošanas struktūrai ir divas īpašības: ražotājs un patērētājs.
Ražotāju grupa, ko izmanto, lai attēlotu ziņojumapmaiņas lietojumprogrammu, satur vairākas ražotāju instances, kas var būt vairākas mašīnas, vairāki mašīnas procesi vai vairāki procesa ražotāja objekti. Producentu grupa var nosūtīt vairākus tēmas ziņojumus, un ražotāju grupa darbojas šādi:
- Identificējiet ražotāja veidu
- Varat vaicāt, vai šajā ziņojumapmaiņas lietojumprogrammā ir vairākas ražotāja instances, izmantojot O&M rīku
- Nosūtot izplatītu darījuma ziņojumu, ja ražotājs negaidīti pazūd, brokeris aktīvi piezvanīs jebkurai ražotāju grupas mašīnai, lai apstiprinātu darījuma statusu.
Patērētāju grupa, ko izmanto, lai attēlotu patērētāju ziņojumapmaiņas lietojumprogrammu, satur vairākas patērētāju instances, kas var būt vairākas mašīnas, vairāki procesi vai vairāki procesa patērētāju objekti. Vairāki patērētāji patērētāju grupā patērē ziņojumus vienmērīgi sadalītā veidā, un, ja tas ir iestatīts apraidei, katrs šīs patērētāju grupas gadījums patērē visu datu apjomu.
RocketMQ datu glabāšanas struktūra
Kā parādīts iepriekš redzamajā attēlā, RocketMQ izmanto glabāšanas metodi, kas atdala datus no indeksiem. Efektīvi samaziniet failu resursu, IO resursu un atmiņas resursu zudumu. Pat ar milzīgiem datiem, piemēram, Alibaba, augstas vienlaicīguma scenāriji var efektīvi samazināt latentumu no gala līdz galam un tiem ir spēcīgas horizontālās mērogošanas iespējas.
|
Publicēts 28.07.2017 20:26:52
|
|
|
|
Publicēts 29.07.2017 08:09:37