ProHoster > Blogs > Administrācija > Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka

Mazas grāmatiņas tulkojuma turpinājums:
Izpratne par ziņojumu brokeriem
autors: Jakubs Korabs, izdevējs: O'Reilly Media, Inc., publicÄ“Å”anas datums: 2017. gada jÅ«nijs, ISBN: 9781492049296.

IepriekŔējā tulkotā daļa: Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 1. nodaļa Ievads

3. NODAĻA

Kafka

Kafka izstrādāja LinkedIn, lai apietu dažus tradicionālo ziņojumu starpnieku ierobežojumus un izvairÄ«tos no nepiecieÅ”amÄ«bas iestatÄ«t vairākus ziņojumu starpniekus dažādām mijiedarbÄ«bām no viena punkta uz otru, kas ir aprakstÄ«ts Ŕīs grāmatas sadaļā "PalielināŔana un samazināŔana" 28. lpp. LietoÅ”anas gadÄ«jumi LinkedIn lielā mērā ir paļāvies uz ļoti liela datu apjoma, piemēram, lapu klikŔķu un piekļuves žurnālu, vienvirziena ievadÄ«Å”anu, vienlaikus ļaujot Å”os datus izmantot vairākām sistēmām, neietekmējot ražotāju vai citu patērētāju produktivitāti. Faktiski Kafkas pastāvÄ“Å”anas iemesls ir iegÅ«t tādu ziņojumapmaiņas arhitektÅ«ru, kādu apraksta Universal Data Pipeline.

Ņemot vērā Å”o galÄ«go mērÄ·i, dabiski radās citas prasÄ«bas. Kafkam vajadzētu:

  • Esiet ārkārtÄ«gi ātrs
  • NodroÅ”iniet lielāku joslas platumu, strādājot ar ziņojumiem
  • Atbalstiet izdevēja-abonenta un punkta-punkta modeļus
  • Nebremzējiet, pievienojot patērētājus. Piemēram, gan rindas, gan tēmas veiktspēja programmā ActiveMQ pasliktinās, jo galamērÄ·Ä« pieaug patērētāju skaits.
  • jābÅ«t horizontāli mērogojamam; ja viens starpnieks, kurÅ” saglabā ziņojumus, var to darÄ«t tikai ar maksimālo diska ātrumu, tad ir lietderÄ«gi izmantot vairāk nekā vienu starpnieka gadÄ«jumu, lai palielinātu veiktspēju.
  • Ierobežojiet piekļuvi ziņojumu glabāŔanai un atkārtotai izgÅ«Å”anai

Lai to visu panāktu, Kafka pieņēma arhitektÅ«ru, kas no jauna definēja klientu un ziņojumapmaiņas brokeru lomas un pienākumus. JMS modelis ir ļoti orientēts uz brokeri, kur brokeris ir atbildÄ«gs par ziņojumu izplatÄ«Å”anu un klientiem ir jāuztraucas tikai par ziņojumu nosÅ«tÄ«Å”anu un saņemÅ”anu. Savukārt Kafka ir orientēta uz klientu, un klients uzņemas daudzas tradicionālā brokera funkcijas, piemēram, godÄ«gu atbilstoÅ”u ziņojumu izplatÄ«Å”anu patērētājiem, apmaiņā pret ārkārtÄ«gi ātru un mērogojamu brokeri. Cilvēkiem, kuri ir strādājuÅ”i ar tradicionālajām ziņojumapmaiņas sistēmām, darbs ar Kafku prasa fundamentālas domāŔanas izmaiņas.
Å is inženierijas virziens ir ļāvis izveidot ziņojumapmaiņas infrastruktÅ«ru, kas spēj palielināt caurlaidspēju par daudzām kārtām salÄ«dzinājumā ar parasto brokeri. Kā mēs redzēsim, Ŕī pieeja nāk ar kompromisiem, kas nozÄ«mē, ka Kafka nav piemērota noteikta veida darba slodzei un instalētai programmatÅ«rai.

Vienotais galamērķa modelis

Lai izpildÄ«tu iepriekÅ” aprakstÄ«tās prasÄ«bas, Kafka ir apvienojis publicÄ“Å”anu-abonÄ“Å”anu un ziņojumapmaiņu no viena punkta uz vienu galamērÄ·i. temats. Tas mulsina cilvēkus, kuri ir strādājuÅ”i ar ziņojumapmaiņas sistēmām, kur vārds "tēma" attiecas uz apraides mehānismu, no kura (no tēmas) lasÄ«Å”ana nav ilgstoÅ”a. Kafkas tēmas ir jāuzskata par hibrÄ«da galamērÄ·a veidu, kā noteikts Ŕīs grāmatas ievadā.

Å Ä«s nodaļas atlikuÅ”ajā daļā, ja vien mēs nepārprotami nenorādÄ«sim citādi, termins "tēma" attiecas uz Kafkas tēmu.

Lai pilnībā saprastu, kā tēmas uzvedas un kādas garantijas tās sniedz, vispirms ir jāaplūko, kā tās tiek īstenotas Kafkā.
Katrai Kafkas tēmai ir savs žurnāls.
Ražotāji, kas sÅ«ta ziņojumus Kafkai, raksta Å”ajā žurnālā, un patērētāji lasa no žurnāla, izmantojot norādes, kas pastāvÄ«gi virzās uz priekÅ”u. Periodiski Kafka dzÄ“Å” vecākās žurnāla daļas neatkarÄ«gi no tā, vai ziņojumi Å”ajās daļās ir lasÄ«ti vai nē. Kafkas dizaina galvenā daļa ir tāda, ka brokerim ir vienalga, vai ziņojumi tiek lasÄ«ti vai nē ā€“ tā ir klienta atbildÄ«ba.

Termini "žurnāls" un "rādÄ«tājs" neparādās Kafkas dokumentācija. Å ie labi zināmie termini Å”eit tiek lietoti, lai palÄ«dzētu saprast.

Å is modelis pilnÄ«gi atŔķiras no ActiveMQ, kur ziņojumi no visām rindām tiek glabāti vienā žurnālā, un brokeris atzÄ«mē ziņojumus kā izdzēstus pēc to izlasÄ«Å”anas.
Tagad iedziļināsimies mazliet dziļāk un apskatīsim tēmu žurnālu sīkāk.
Kafka žurnāls sastāv no vairākām starpsienām (Skaitlis 3-1). Kafka garantē stingru pasÅ«tÄ«Å”anu katrā nodalÄ«jumā. Tas nozÄ«mē, ka ziņojumi, kas rakstÄ«ti nodalÄ«jumā noteiktā secÄ«bā, tiks nolasÄ«ti tādā paŔā secÄ«bā. Katrs nodalÄ«jums tiek Ä«stenots kā ritoÅ”ais žurnālfails, kas satur apakÅ”kopa (apakÅ”kopa) no visiem ziņojumiem, ko tēmai nosÅ«tÄ«juÅ”i tās veidotāji. Izveidotajā tēmā pēc noklusējuma ir viens nodalÄ«jums. Starpsienu ideja ir Kafkas galvenā ideja par horizontālo mērogoÅ”anu.

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka
Attēls 3-1. Kafka starpsienas

Kad producents nosūta ziņojumu Kafkas tēmai, tas izlemj, uz kuru nodalījumu nosūtīt ziņojumu. Mēs to aplūkosim sīkāk vēlāk.

Ziņu lasÄ«Å”ana

Klients, kas vēlas lasīt ziņojumus, pārvalda nosauktu rādītāju patērētāju grupa, kas norāda uz kompensēt ziņojumi nodalījumā. Nobīde ir pakāpeniska pozīcija, kas sākas ar 0 nodalījuma sākumā. Šī patērētāju grupa, kas norādīta API, izmantojot lietotāja definēto grupas_id, atbilst viens loģisks patērētājs vai sistēma.

Lielākā daļa ziņojumapmaiņas sistēmu nolasa datus no galamērķa, izmantojot vairākus gadījumus un pavedienus, lai paralēli apstrādātu ziņojumus. Tādējādi parasti ir daudz patērētāju gadījumu, kuriem ir viena un tā pati patērētāju grupa.

LasÄ«Å”anas problēmu var attēlot Ŕādi:

  • Tēmai ir vairākas sadaļas
  • Vairākas patērētāju grupas var izmantot tēmu vienlaikus
  • Patērētāju grupai var bÅ«t vairāki atseviŔķi gadÄ«jumi

Å Ä« ir netriviāla daudzu pret daudziem problēma. Lai saprastu, kā Kafka apstrādā attiecÄ«bas starp patērētāju grupām, patērētāju gadÄ«jumiem un nodalÄ«jumiem, apskatÄ«sim vairākus pakāpeniski sarežģītākus lasÄ«Å”anas scenārijus.

Patērētāji un patērētāju grupas

Ņemsim par sākumpunktu tēmu ar vienu nodalījumu (Skaitlis 3-2).

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka
Attēls 3-2. Patērētājs lasa no nodalījuma

Kad patērētāja instance Å”ai tēmai izveido savienojumu ar savu group_id, tai tiek pieŔķirts lasÄ«Å”anas nodalÄ«jums un nobÄ«de Å”ajā nodalÄ«jumā. Å Ä«s nobÄ«des pozÄ«cija klientā ir konfigurējama kā rādÄ«tājs uz jaunāko pozÄ«ciju (jaunākais ziņojums) vai agrāko pozÄ«ciju (vecākais ziņojums). Patērētājs pieprasa (aptaujā) ziņas no tēmas, kas liek tos secÄ«gi nolasÄ«t no žurnāla.
NobÄ«des pozÄ«cija regulāri tiek atgriezta Kafkai un tiek saglabāta kā ziņojumi iekŔējā tēmā _patērētāju_kompensācijas. AtŔķirÄ«bā no parasta brokera lasÄ«tās ziņas joprojām netiek izdzēstas, un klients var attÄ«t nobÄ«di, lai atkārtoti apstrādātu jau skatÄ«tos ziņojumus.

Kad otrs loÄ£iskais patērētājs izveido savienojumu, izmantojot citu group_id, tas pārvalda otru rādÄ«tāju, kas ir neatkarÄ«gs no pirmā (Skaitlis 3-3). Tādējādi Kafka tēma darbojas kā rinda, kurā ir viens patērētājs, un kā parasta publikācijas-abonÄ“Å”anas (pub-abonÄ“Å”anas) tēma, kuru abonē vairāki patērētāji, kā arÄ« papildu ieguvums, ka visi ziņojumi tiek saglabāti un tos var apstrādāt vairākas reizes.

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka
Attēls 3-3. Divi patērētāji dažādās patērētāju grupās lasa no viena nodalījuma

Patērētāji patērētāju grupā

Kad viena patērētāja instance nolasa datus no nodalÄ«juma, tā pilnÄ«bā kontrolē rādÄ«tāju un apstrādā ziņojumus, kā aprakstÄ«ts iepriekŔējā sadaļā.
Ja vairāki patērētāju gadÄ«jumi ar vienu un to paÅ”u group_id bija saistÄ«ti ar tēmu ar vienu nodalÄ«jumu, tad instancei, kas savienojās pēdējā, tiks dota kontrole pār rādÄ«tāju un no Ŕī brīža tā saņems visus ziņojumus (Skaitlis 3-4).

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka
Attēls 3-4. Divi patērētāji vienā patērētāju grupā lasa no viena nodalījuma

Å o apstrādes veidu, kurā patērētāju gadÄ«jumu skaits pārsniedz nodalÄ«jumu skaitu, var uzskatÄ«t par sava veida ekskluzÄ«vu patērētāju. Tas var bÅ«t noderÄ«gi, ja jums ir nepiecieÅ”ama "aktÄ«va-pasÄ«vā" (vai "karsti-silta") jÅ«su patērētāju gadÄ«jumu klasterizācija, lai gan vairāku patērētāju paralēla darbināŔana ("aktÄ«vais-aktÄ«vs" vai "karsts-karsts") ir daudz raksturÄ«gāka nekā gaidÄ«Å”anas režīmā.

Å Ä« ziņojumu izplatÄ«Å”anas darbÄ«ba, kas aprakstÄ«ta iepriekÅ”, var bÅ«t pārsteidzoÅ”a salÄ«dzinājumā ar parastās JMS rindas darbÄ«bu. Å ajā modelÄ« ziņojumi, kas nosÅ«tÄ«ti uz rindu, tiks vienmērÄ«gi sadalÄ«ti starp diviem patērētājiem.

Visbiežāk, veidojot vairākus patērētāju gadÄ«jumus, mēs to darām, lai paralēli apstrādātu ziņojumus vai palielinātu lasÄ«Å”anas ātrumu, vai arÄ« lai palielinātu lasÄ«Å”anas procesa stabilitāti. Tā kā tikai viens patērētāja gadÄ«jums vienlaikus var nolasÄ«t datus no nodalÄ«juma, kā tas tiek panākts programmā Kafka?

Viens veids, kā to izdarÄ«t, ir izmantot vienu patērētāja gadÄ«jumu, lai izlasÄ«tu visus ziņojumus un nosÅ«tÄ«tu tos pavedienu pÅ«lam. Lai gan Ŕī pieeja palielina apstrādes caurlaidspēju, tā palielina patērētāja loÄ£ikas sarežģītÄ«bu un nepalielina lasÄ«Å”anas sistēmas stabilitāti. Ja viens patērētāja eksemplārs pazÅ«d strāvas padeves pārtraukuma vai lÄ«dzÄ«ga notikuma dēļ, atņemÅ”ana tiek pārtraukta.

Kanoniskais veids, kā atrisināt Å”o problēmu Kafkā, ir izmantot bŠžvairāk starpsienu.

SadalīŔana

Starpsienas ir galvenais mehānisms tēmas lasÄ«Å”anai un mērogoÅ”anai, kas pārsniedz viena starpnieka instances joslas platumu. Lai to labāk izprastu, aplÅ«kosim situāciju, kad ir tēma ar diviem nodalÄ«jumiem un viens patērētājs abonē Å”o tēmu (Skaitlis 3-5).

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka
Attēls 3-5. Viens patērētājs lasa no vairākiem nodalījumiem

Å ajā scenārijā patērētājam tiek dota kontrole pār rādÄ«tājiem, kas atbilst tā grupas_id abos nodalÄ«jumos, un viņŔ sāk lasÄ«t ziņojumus no abiem nodalÄ«jumiem.
Kad Å”ai tēmai tiek pievienots papildu patērētājs tam paÅ”am grupas_id, Kafka pārdala vienu no nodalÄ«jumiem no pirmā uz otro patērētāju. Pēc tam katrs patērētāja gadÄ«jums lasÄ«s no viena tēmas sadaļas (Skaitlis 3-6).

Lai nodroÅ”inātu, ka ziņojumi tiek apstrādāti paralēli 20 pavedienos, ir nepiecieÅ”ami vismaz 20 nodalÄ«jumi. Ja nodalÄ«jumu bÅ«s mazāk, jums paliks patērētāji, kuriem nav pie kā strādāt, kā aprakstÄ«ts iepriekÅ” ekskluzÄ«vo patērētāju diskusijā.

Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 3. nodaļa. Kafka
Attēls 3-6. Divi patērētāji vienā patērētāju grupā lasa no dažādām starpsienām

Å Ä« shēma ievērojami samazina Kafka brokera sarežģītÄ«bu salÄ«dzinājumā ar ziņojumu izplatÄ«Å”anu, kas nepiecieÅ”ama JMS rindas uzturÄ“Å”anai. Å eit jums nav jāuztraucas par Ŕādiem punktiem:

  • Kuram patērētājam jāsaņem nākamais ziņojums, pamatojoties uz apļveida sadalÄ«jumu, paÅ”reizējo sākotnējo ielādes buferu ietilpÄ«bu vai iepriekŔējiem ziņojumiem (kā JMS ziņojumu grupām).
  • Kuri ziņojumi kuriem patērētājiem tiek nosÅ«tÄ«ti un vai tie ir atkārtoti jāpiegādā kļūmes gadÄ«jumā.

Viss, kas Kafka brokerim jādara, ir secīgi nosūtīt ziņojumus patērētājam, kad tas tos pieprasa.

Tomēr prasÄ«bas par neizdevuÅ”os ziņojumu korektÅ«ru un atkārtotu nosÅ«tÄ«Å”anu nekur nepazÅ«d ā€“ atbildÄ«ba par tām vienkārÅ”i pāriet no brokera uz klientu. Tas nozÄ«mē, ka tie ir jāņem vērā jÅ«su kodā.

Ziņu sÅ«tÄ«Å”ana

Å Ä« ziņojuma veidotājs ir atbildÄ«gs par izlemÅ”anu, uz kuru nodalÄ«jumu nosÅ«tÄ«t ziņojumu. Lai saprastu mehānismu, ar kuru tas tiek darÄ«ts, mums vispirms ir jāapsver, ko tieÅ”i mēs patiesÄ«bā sÅ«tām.

Ja JMS mēs izmantojam ziņojuma struktÅ«ru ar metadatiem (galvenēm un rekvizÄ«tiem) un pamattekstu, kas satur lietderÄ«go slodzi (payload), Kafkā ziņojums ir pāris "atslēgas vērtÄ«ba". Ziņojuma slodze tiek nosÅ«tÄ«ta kā vērtÄ«ba. No otras puses, atslēga galvenokārt tiek izmantota sadalÄ«Å”anai, un tai ir jābÅ«t biznesa loÄ£ikai specifiska atslēgalai vienā nodalÄ«jumā ievietotu saistÄ«tos ziņojumus.

2. nodaļā mēs apspriedām tieÅ”saistes derÄ«bu scenāriju, kurā saistÄ«tie notikumi ir jāapstrādā secÄ«bā vienam patērētājam:

  1. Lietotāja konts ir konfigurēts.
  2. Nauda tiek ieskaitīta kontā.
  3. Tiek veikta likme, kas izņem naudu no konta.

Ja katrs notikums ir ziņojums, kas publicēts tēmā, dabiskā atslēga bÅ«tu konta ID.
Kad ziņojums tiek nosÅ«tÄ«ts, izmantojot Kafka Producer API, tas tiek nodots nodalÄ«juma funkcijai, kas, ņemot vērā ziņojumu un paÅ”reizējo Kafka klastera stāvokli, atgriež tā nodalÄ«juma ID, uz kuru ziņojums jānosÅ«ta. Å Ä« funkcija ir ieviesta Java, izmantojot nodalÄ«juma saskarni.

Šis interfeiss izskatās Ŕādi:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

SadalÄ«Å”anas implementācija izmanto noklusējuma vispārējas nozÄ«mes jaukÅ”anas algoritmu virs atslēgas, lai noteiktu nodalÄ«jumu, vai apļveida pārbaudi, ja atslēga nav norādÄ«ta. Å Ä« noklusējuma vērtÄ«ba vairumā gadÄ«jumu darbojas labi. Tomēr nākotnē jÅ«s vēlaties rakstÄ«t savu.

Savas sadalÄ«Å”anas stratēģijas rakstÄ«Å”ana

ApskatÄ«sim piemēru, kur vēlaties nosÅ«tÄ«t metadatus kopā ar ziņojuma slodzi. MÅ«su piemērā lietderÄ«gā slodze ir instrukcija veikt iemaksu spēles kontā. Instrukcija ir kaut kas tāds, par kuru mēs vēlamies, lai pārsÅ«tÄ«Å”anas laikā netiktu mainÄ«ti, un mēs vēlamies bÅ«t pārliecināti, ka tikai uzticama augÅ”upējā sistēma var ierosināt Å”o norādÄ«jumu. Å ajā gadÄ«jumā sÅ«tÄ«Å”anas un saņemÅ”anas sistēmas vienojas par paraksta izmantoÅ”anu ziņojuma autentificÄ“Å”anai.
Parastā JMS mēs vienkārÅ”i definējam rekvizÄ«tu "ziņojuma paraksts" un pievienojam to ziņojumam. Tomēr Kafka nenodroÅ”ina mums metadatu nodoÅ”anas mehānismu, tikai atslēgu un vērtÄ«bu.

Tā kā vērtÄ«ba ir bankas pārveduma lietderÄ«gā slodze, kuras integritāti mēs vēlamies saglabāt, mums nav citas izvēles, kā definēt atslēgā izmantojamo datu struktÅ«ru. Pieņemot, ka sadalÄ«Å”anai mums ir nepiecieÅ”ams konta ID, jo visi ar kontu saistÄ«tie ziņojumi ir jāapstrādā secÄ«bā, mēs izstrādāsim Ŕādu JSON struktÅ«ru:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

Tā kā paraksta vērtÄ«ba mainÄ«sies atkarÄ«bā no lietderÄ«gās slodzes, nodalÄ«juma interfeisa noklusējuma jaukÅ”anas stratēģija nevar droÅ”i grupēt saistÄ«tos ziņojumus. Tāpēc mums bÅ«s jāraksta sava stratēģija, kas parsēs Å”o atslēgu un sadalÄ«s accountId vērtÄ«bu.

Kafka ietver kontrolsummas, lai noteiktu veikalā esoÅ”o ziņojumu bojājumus, un tai ir pilns droŔības lÄ«dzekļu komplekts. Tomēr dažkārt parādās nozarei specifiskas prasÄ«bas, piemēram, iepriekÅ” minētā.

Lietotāja sadalÄ«Å”anas stratēģijai ir jānodroÅ”ina, ka visi saistÄ«tie ziņojumi nonāk tajā paŔā nodalÄ«jumā. Lai gan tas Ŕķiet vienkārÅ”i, prasÄ«bu var sarežģīt saistÄ«tu ziņojumu pasÅ«tÄ«Å”anas nozÄ«me un tas, cik fiksēts ir sadaļas skaits tēmā.

Tēmas nodalījumu skaits laika gaitā var mainīties, jo tos var pievienot, ja trafiks pārsniedz sākotnējās cerības. Tādējādi ziņojumu atslēgas var saistīt ar nodalījumu, uz kuru tās sākotnēji tika nosūtītas, kas nozīmē, ka valsts daļa ir jāsadala starp ražotāja gadījumiem.

Vēl viens faktors, kas jāņem vērā, ir vienmērÄ«ga ziņojumu sadale starp nodalÄ«jumiem. Parasti atslēgas ziņojumos netiek sadalÄ«tas vienmērÄ«gi, un jaukÅ”anas funkcijas negarantē taisnÄ«gu ziņojumu sadali nelielai atslēgu kopai.
Ir svarīgi ņemt vērā, ka neatkarīgi no tā, vai izvēlaties sadalīt ziņojumus, pats atdalītājs, iespējams, būs jāizmanto atkārtoti.

Apsveriet prasību replicēt datus starp Kafka klasteriem dažādās ģeogrāfiskās vietās. Šim nolūkam Kafka ir aprīkots ar komandrindas rīku MirrorMaker, ko izmanto, lai lasītu ziņojumus no viena klastera un pārsūtītu tos uz citu.

MirrorMaker ir jāsaprot replicētās tēmas atslēgas, lai saglabātu relatÄ«vo kārtÄ«bu starp ziņojumiem, veicot replicÄ“Å”anu starp klasteriem, jo ā€‹ā€‹Å”Ä«s tēmas nodalÄ«jumu skaits var atŔķirties divos klasteros.

Pielāgotas sadalÄ«Å”anas stratēģijas ir salÄ«dzinoÅ”i reti sastopamas, jo noklusējuma jaukÅ”ana vai apļveida sistēma darbojas labi vairumā gadÄ«jumu. Tomēr, ja jums ir nepiecieÅ”amas stingras pasÅ«tÄ«Å”anas garantijas vai ir jāizņem metadati no lietderÄ«gās slodzes, sadalÄ«Å”ana ir kaut kas, kas jums jāaplÅ«ko sÄ«kāk.

Kafka mērogojamÄ«bas un veiktspējas priekÅ”rocÄ«bas rodas, dažus tradicionālā brokera pienākumus nododot klientam. Å ajā gadÄ«jumā tiek pieņemts lēmums izplatÄ«t potenciāli saistÄ«tus ziņojumus starp vairākiem patērētājiem, kas strādā paralēli.

Ar Ŕādām prasÄ«bām jātiek galā arÄ« JMS brokeriem. Interesanti, ka mehānisms saistÄ«tu ziņojumu nosÅ«tÄ«Å”anai vienam un tam paÅ”am patērētājam, kas tiek ieviests, izmantojot JMS ziņojumu grupas (stingrās slodzes lÄ«dzsvaroÅ”anas (SLB) stratēģijas variants), arÄ« prasa, lai sÅ«tÄ«tājs atzÄ«mētu ziņojumus kā saistÄ«tus. JMS gadÄ«jumā brokeris ir atbildÄ«gs par Ŕīs saistÄ«to ziņojumu grupas nosÅ«tÄ«Å”anu vienam patērētājam un grupas Ä«paÅ”umtiesÄ«bu nodoÅ”anu, ja patērētājs atsakās.

Ražotāju līgumi

SadalÄ«Å”ana nav vienÄ«gā lieta, kas jāņem vērā, sÅ«tot ziņojumus. ApskatÄ«sim Java API Producer klases send() metodes:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

Uzreiz jāatzÄ«mē, ka abas metodes atgriež Future, kas norāda, ka nosÅ«tÄ«Å”anas darbÄ«ba netiek veikta uzreiz. Rezultātā ziņojums (ProducerRecord) tiek ierakstÄ«ts katra aktÄ«vā nodalÄ«juma sÅ«tÄ«Å”anas buferÄ« un nosÅ«tÄ«ts brokerim kā fona pavediens Kafka klienta bibliotēkā. Lai gan tas padara lietas neticami ātri, tas nozÄ«mē, ka nepieredzējuÅ”a lietojumprogramma var zaudēt ziņojumus, ja tās process tiek apturēts.

Kā vienmēr, ir veids, kā padarÄ«t nosÅ«tÄ«Å”anas darbÄ«bu uzticamāku par veiktspējas rēķina. Å Ä« bufera lielumu var iestatÄ«t uz 0, un sÅ«tÄ«Å”anas lietojumprogrammas pavediens bÅ«s spiests gaidÄ«t, lÄ«dz tiks pabeigta ziņojuma pārsÅ«tÄ«Å”ana brokerim:

RecordMetadata metadata = producer.send(record).get();

Vairāk par ziņojumu lasÄ«Å”anu

Ziņojumu lasÄ«Å”ana rada papildu sarežģījumus, par kuriem ir jādomā. AtŔķirÄ«bā no JMS API, kas var palaist ziņojumu uztvērēju, reaģējot uz ziņojumu, Patērētājs Kafka tikai aptaujas. ApskatÄ«sim metodi tuvāk aptauja ()izmanto Å”im nolÅ«kam:

ConsumerRecords < K, V > poll(long timeout);

Metodes atgrieÅ”anas vērtÄ«ba ir konteinera struktÅ«ra, kurā ir vairāki objekti patērētāju ieraksts no potenciāli vairākām starpsienām. patērētāju ieraksts pats par sevi ir atslēgas-vērtÄ«bas pāra turētāja objekts ar saistÄ«tajiem metadatiem, piemēram, nodalÄ«jumu, no kura tas ir iegÅ«ts.

Kā minēts 2. nodaļā, mums jāpatur prātā, kas notiek ar ziņojumiem pēc tam, kad tie ir veiksmīgi vai neveiksmīgi apstrādāti, piemēram, ja klients nevar apstrādāt ziņojumu vai tas tiek pārtraukts. JMS tas tika apstrādāts, izmantojot apstiprinājuma režīmu. Brokeris vai nu izdzēsīs veiksmīgi apstrādāto ziņojumu, vai atkārtoti piegādās neapstrādātu vai viltotu ziņojumu (pieņemot, ka tika izmantoti darījumi).
Kafka darbojas ļoti atŔķirÄ«gi. Ziņojumi brokerÄ« netiek dzēsti pēc korektÅ«ras, un par to, kas notiek neveiksmes gadÄ«jumā, ir atbildÄ«gs pats korektÅ«ras kods.

Kā jau teicām, patērētāju grupa ir saistÄ«ta ar nobÄ«di žurnālā. Žurnāla pozÄ«cija, kas saistÄ«ta ar Å”o nobÄ«di, atbilst nākamajam ziņojumam, kas jāizdod, atbildot uz to aptauja (). Laiks, kad Ŕī nobÄ«de palielinās, ir noteicoÅ”ais lasÄ«Å”anai.

Atgriežoties pie iepriekÅ” apspriestā lasÄ«Å”anas modeļa, ziņojumu apstrāde sastāv no trim posmiem:

  1. IzgÅ«t ziņojumu lasÄ«Å”anai.
  2. Apstrādājiet ziņojumu.
  3. Apstipriniet ziņojumu.

Kafka patērētājam ir konfigurācijas opcija enable.auto.commit. Šis ir bieži izmantots noklusējuma iestatījums, tāpat kā iestatījumos, kuros ir vārds "auto".

Pirms Kafka 0.10 klients, kurÅ” izmantoja Å”o opciju, nākamajā zvanā nosÅ«tÄ«ja pēdējā nolasÄ«tā ziņojuma nobÄ«di aptauja () pēc apstrādes. Tas nozÄ«mēja, ka visus jau ienestos ziņojumus varēja atkārtoti apstrādāt, ja klients tos jau bija apstrādājis, bet tika negaidÄ«ti iznÄ«cināts pirms zvanÄ«Å”anas. aptauja (). Tā kā brokeris nesaglabā ziņas par to, cik reižu ziņojums ir lasÄ«ts, nākamais patērētājs, kurÅ” izgÅ«s Å”o ziņojumu, neuzzinās, ka nekas slikts ir noticis. Šāda rÄ«cÄ«ba bija pseidodarÄ«jums. NobÄ«de tika veikta tikai tad, ja ziņojums tika veiksmÄ«gi apstrādāts, bet, ja klients to pārtrauc, brokeris vēlreiz nosÅ«tÄ«s to paÅ”u ziņojumu citam klientam. Å Ä« rÄ«cÄ«ba atbilda ziņojumu piegādes garantijai "vismaz vienreiz".

Programmā Kafka 0.10 klienta kods ir mainÄ«ts tā, lai klienta bibliotēka periodiski aktivizētu apņemÅ”anos, kā tas ir konfigurēts auto.commit.interval.ms. Å Ä« darbÄ«ba ir kaut kur starp režīmiem JMS AUTO_ACKNOWLEDGE un DUPS_OK_ACKNOWLEDGE. Izmantojot automātisko apņemÅ”anos, ziņojumus var veikt neatkarÄ«gi no tā, vai tie faktiski tika apstrādāti ā€“ tas varētu notikt lēna patērētāja gadÄ«jumā. Ja patērētājs pārtrauc darbu, ziņojumus ienesÄ«s nākamais patērētājs, sākot no noteiktās pozÄ«cijas, kā rezultātā ziņojums var tikt palaists garām. Å ajā gadÄ«jumā Kafka nezaudēja ziņojumus, lasÄ«Å”anas kods tos vienkārÅ”i neapstrādāja.

Å im režīmam ir tāds pats solÄ«jums kā versijā 0.9: ziņojumus var apstrādāt, taču, ja tas neizdodas, nobÄ«de var netikt veikta, un tas var izraisÄ«t piegādes dubultoÅ”anos. Jo vairāk ziņojumu jÅ«s ienesat izpildes laikā aptauja (), jo vairāk Ŕī problēma.

Kā aprakstÄ«ts sadaļā ā€œZiņojumu lasÄ«Å”ana no rindasā€ 21. lpp., ziņojumapmaiņas sistēmā nav tādas lietas kā vienreizēja ziņojuma piegāde, ja tiek ņemti vērā atteices režīmi.

Kafkā ir divi veidi, kā veikt (iesaistÄ«t) nobÄ«di (nobÄ«di): automātiski un manuāli. Abos gadÄ«jumos ziņojumus var apstrādāt vairākas reizes, ja ziņojums tika apstrādāts, bet neizdevās pirms apstiprināŔanas. Varat arÄ« izvēlēties neapstrādāt ziņojumu vispār, ja apņemÅ”anās notika fonā un jÅ«su kods tika pabeigts, pirms to varēja apstrādāt (iespējams, Kafka 0.9 un vecākā versijā).

Varat kontrolēt manuālās nobÄ«des izpildes procesu Kafka patērētāju API, iestatot parametru enable.auto.commit nepatiesi un nepārprotami izsaucot vienu no Ŕīm metodēm:

void commitSync();
void commitAsync();

Ja vēlaties apstrādāt ziņojumu "vismaz vienu reizi", nobÄ«de jāveic manuāli ar commitSync()izpildot Å”o komandu tÅ«lÄ«t pēc ziņojumu apstrādes.

Å Ä«s metodes neļauj apstiprināt ziņojumus pirms to apstrādes, taču tās neko nedara, lai novērstu iespējamos apstrādes aizkaves, vienlaikus radot darÄ«juma iespaidu. Kafkā nav darÄ«jumu. Klientam nav iespēju veikt Ŕādas darbÄ«bas:

  • Automātiski atgriezt viltotu ziņojumu. Patērētājiem paÅ”iem ir jārisina izņēmumi, kas rodas no problemātiskām lietderÄ«gām slodzēm un aizmugursistēmas darbÄ«bas pārtraukumiem, jo ā€‹ā€‹viņi nevar paļauties uz brokeri, lai atkārtoti piegādātu ziņojumus.
  • NosÅ«tiet ziņojumus uz vairākām tēmām vienā kodolā. Kā mēs drÄ«z redzēsim, dažādu tēmu un nodalÄ«jumu kontrole var bÅ«t dažādās Kafka klastera iekārtās, kas nekoordinē darÄ«jumus, kad tie tiek nosÅ«tÄ«ti. Å Ä«s rakstÄ«Å”anas laikā tika veikts zināms darbs, lai tas bÅ«tu iespējams ar KIP-98.
  • Saistiet vienas ziņas lasÄ«Å”anu no vienas tēmas ar citas ziņas nosÅ«tÄ«Å”anu uz citu tēmu. Atkal, Kafkas arhitektÅ«ra ir atkarÄ«ga no daudzām neatkarÄ«gām maŔīnām, kas darbojas kā viens autobuss, un to nemēģina slēpt. Piemēram, nav API komponentu, kas ļautu izveidot saiti patērētājs Šø Producents darÄ«jumā. JMS to nodroÅ”ina objekts sesijano kuriem tiek izveidoti MessageProducers Šø MessageConsumers.

Ja mēs nevaram paļauties uz darÄ«jumiem, kā mēs varam nodroÅ”ināt semantiku, kas ir tuvāka tai, ko nodroÅ”ina tradicionālās ziņojumapmaiņas sistēmas?

Ja pastāv iespēja, ka patērētāja kompensācija var palielināties pirms ziņojuma apstrādes, piemēram, patērētāja avārijas laikā, tad patērētājs nevar zināt, vai viņa patērētāju grupa palaida garām ziņojumu, kad tai tiek pieŔķirts nodalÄ«jums. Tātad viena stratēģija ir pārtÄ«t nobÄ«di uz iepriekŔējo pozÄ«ciju. Kafka patērētāju API nodroÅ”ina Ŕādas metodes:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

Metode meklēt () var izmantot ar metodi
offsetsFor Times (karte laikspiedoli meklÄ“Å”anai) lai attÄ«tu atpakaļ uz stāvokli kādā konkrētā pagātnes punktā.

Å Ä«s pieejas izmantoÅ”ana netieÅ”i nozÄ«mē, ka ir ļoti iespējams, ka daži iepriekÅ” apstrādātie ziņojumi tiks lasÄ«ti un apstrādāti vēlreiz. Lai no tā izvairÄ«tos, mēs varam izmantot idempotentu lasÄ«Å”anu, kā aprakstÄ«ts 4. nodaļā, lai izsekotu iepriekÅ” skatÄ«tajiem ziņojumiem un novērstu dublikātus.

AlternatÄ«vi, jÅ«su patērētāja kods var bÅ«t vienkārÅ”s, ja vien ir pieļaujams ziņojumu zudums vai dublÄ“Å”anās. Apsverot lietoÅ”anas gadÄ«jumus, kuriem parasti tiek izmantots Kafka, piemēram, žurnāla notikumu, metrikas, klikŔķu izsekoÅ”anas u.c. apstrādi, mēs saprotam, ka atseviŔķu ziņojumu zaudÄ“Å”ana, visticamāk, bÅ«tiski neietekmēs apkārtējās lietojumprogrammas. Šādos gadÄ«jumos noklusējuma vērtÄ«bas ir pilnÄ«gi pieņemamas. No otras puses, ja jÅ«su pieteikumam ir nepiecieÅ”ams nosÅ«tÄ«t maksājumus, jums rÅ«pÄ«gi jārÅ«pējas par katru atseviŔķu ziņojumu. Tas viss ir atkarÄ«gs no konteksta.

PersonÄ«gie novērojumi liecina, ka, pieaugot ziņojumu intensitātei, katra atseviŔķa ziņojuma vērtÄ«ba samazinās. Lieli ziņojumi mēdz bÅ«t vērtÄ«gi, ja tie tiek skatÄ«ti apkopotā veidā.

Augsta pieejamība

Kafkas pieeja augstajai pieejamÄ«bai ļoti atŔķiras no ActiveMQ pieejas. Kafka ir veidota ap scal-out klasteriem, kur visas brokeru instances saņem un izplata ziņojumus vienlaikus.

Kafka klasteris sastāv no vairākiem brokeru gadÄ«jumiem, kas darbojas dažādos serveros. Kafka tika izstrādāta, lai darbotos ar parastu savrupu aparatÅ«ru, kur katram mezglam ir sava krātuve. Nav ieteicams izmantot tÄ«klam pievienoto krātuvi (SAN), jo vairāki skaitļoÅ”anas mezgli var konkurēt par laiku.Š«e uzglabāŔanas intervālus un radÄ«t konfliktus.

Kafka ir vienmēr sistēma. Daudzi lieli Kafka lietotāji nekad neizslēdz klasterus, un programmatÅ«ra vienmēr tiek atjaunināta ar secÄ«gu restartÄ“Å”anu. Tas tiek panākts, garantējot ziņojumu un brokeru mijiedarbÄ«bas saderÄ«bu ar iepriekŔējo versiju.

Brokeri ir savienoti ar serveru kopu Zoodārza uzraugs, kas darbojas kā konfigurācijas datu reÄ£istrs un tiek izmantots katra brokera lomu koordinÄ“Å”anai. ZooKeeper pati par sevi ir izplatÄ«ta sistēma, kas nodroÅ”ina augstu pieejamÄ«bu, izmantojot informācijas replikāciju, izveidojot kvorums.

Pamata gadÄ«jumā tēma tiek izveidota Kafka klasterÄ« ar Ŕādiem rekvizÄ«tiem:

  • Starpsienu skaits. Kā minēts iepriekÅ”, precÄ«za Å”eit izmantotā vērtÄ«ba ir atkarÄ«ga no vēlamā paralēlās nolasÄ«Å”anas lÄ«meņa.
  • Replikācijas faktors (faktors) nosaka, cik brokeru gadÄ«jumos klasterÄ« ir jāietver Ŕī nodalÄ«juma žurnāli.

Koordinācijai izmantojot ZooKeepers, Kafka mēģina godīgi sadalīt jaunas starpsienas starp klastera brokeriem. To veic viens gadījums, kas darbojas kā kontrolieris.

Izpildes laikā katram tēmas nodalÄ«jumam Kontrolieris pieŔķirt lomas brokerim vadÄ«tājs (vadÄ«tājs, meistars, vadÄ«tājs) un sekotāji (sekotāji, vergi, padotie). Brokeris, kas darbojas kā Ŕīs sadaļas vadÄ«tājs, ir atbildÄ«gs par visu ražotāju nosÅ«tÄ«to ziņojumu saņemÅ”anu un ziņojumu izplatÄ«Å”anu patērētājiem. Kad ziņojumi tiek nosÅ«tÄ«ti uz tēmu nodalÄ«jumu, tie tiek replicēti visos starpnieka mezglos, kas darbojas kā Ŕī nodalÄ«juma sekotāji. Tiek izsaukts katrs mezgls, kurā ir nodalÄ«juma žurnāli replika. Brokeris var darboties kā vadÄ«tājs dažām starpsienām un kā sekotājs citām.

Tiek izsaukts sekotājs, kurā ir visi lÄ«dera ziņojumi sinhronizēta kopija (reprodukcija, kas atrodas sinhronizētā stāvoklÄ«, sinhronizēta kopija). Ja starpnieks, kas darbojas kā nodalÄ«juma vadÄ«tājs, zaudē savu darbÄ«bu, jebkurÅ” brokeris, kas ir atjaunināts vai sinhronizēts ar Å”o nodalÄ«jumu, var pārņemt lÄ«dera lomu. Tas ir neticami ilgtspējÄ«gs dizains.

Daļa no ražotāja konfigurācijas ir parametrs acks, kas nosaka, cik replikām ir jāapstiprina (jāapstiprina) ziņojuma saņemÅ”ana, pirms lietojumprogrammas pavediens turpina sÅ«tÄ«Å”anu: 0, 1 vai visas. Ja iestatÄ«ts uz visi, tad, kad tiek saņemts ziņojums, vadÄ«tājs nosÅ«tÄ«s apstiprinājumu atpakaļ producentam, tiklÄ«dz tas saņems ieraksta apstiprinājumus (apstiprinājumus) no vairākiem signāliem (ieskaitot sevi), ko nosaka tēmas iestatÄ«jums. min.insync.replicas (noklusējums 1). Ja ziņojumu nevar sekmÄ«gi replicēt, ražotājs izliks lietojumprogrammas izņēmumu (NotEnoughReplicas vai NotEnoughReplicasAfterAppend).

Tipiska konfigurācija izveido tēmu ar replikācijas koeficientu 3 (1 vadītājs, 2 sekotāji katrā nodalījumā) un parametru min.insync.replicas ir iestatīts uz 2. Šajā gadījumā klasteris ļaus vienam no brokeriem, kas pārvalda tēmas nodalījumu, pazust, neietekmējot klienta lietojumprogrammas.

Tas mÅ«s atgriež pie jau pazÄ«stamā kompromisa starp veiktspēju un uzticamÄ«bu. Replikācija notiek uz papildu gaidÄ«Å”anas laika, lai saņemtu apstiprinājumus (apstiprinājumus) no sekotājiem. Lai gan, tā kā tā darbojas paralēli, replikācijai vismaz trÄ«s mezglos ir tāda pati veiktspēja kā diviem (neņemot vērā tÄ«kla joslas platuma lietojuma pieaugumu).

Izmantojot Å”o replikācijas shēmu, Kafka gudri izvairās no nepiecieÅ”amÄ«bas katru ziņojumu fiziski ierakstÄ«t diskā ar operāciju sinhronizēt(). Katrs ražotāja nosÅ«tÄ«tais ziņojums tiks ierakstÄ«ts nodalÄ«juma žurnālā, bet, kā aprakstÄ«ts 2. nodaļā, rakstÄ«Å”ana failā sākotnēji tiek veikta operētājsistēmas buferÄ«. Ja Å”is ziņojums tiek pavairots citā Kafka instancē un atrodas tās atmiņā, lÄ«dera zaudÄ“Å”ana nenozÄ«mē, ka ir pazaudēts pats ziņojums ā€“ to var pārņemt sinhronizēta kopija.
Atteikums veikt operāciju sinhronizēt() nozÄ«mē, ka Kafka var saņemt ziņas tikpat ātri, cik spēj ierakstÄ«t tās atmiņā. Un otrādi, jo ilgāk jÅ«s varat izvairÄ«ties no atmiņas izskaloÅ”anas diskā, jo labāk. Å Ä« iemesla dēļ nav nekas neparasts, ka Kafka brokeriem tiek pieŔķirta 64 GB vai vairāk atmiņas. Å is atmiņas lietojums nozÄ«mē, ka viens Kafka gadÄ«jums var viegli darboties ar ātrumu tÅ«kstoÅ”iem reižu ātrāk nekā tradicionālais ziņojumu starpnieks.

Kafka var arÄ« konfigurēt, lai lietotu Å”o darbÄ«bu sinhronizēt() uz ziņojumu pakotnēm. Tā kā viss Kafka ir orientēts uz pakotnēm, tas faktiski darbojas diezgan labi daudzos lietoÅ”anas gadÄ«jumos un ir noderÄ«gs rÄ«ks lietotājiem, kuriem nepiecieÅ”amas ļoti spēcÄ«gas garantijas. Liela daļa Kafkas tÄ«rās veiktspējas izriet no ziņojumiem, kas tiek nosÅ«tÄ«ti brokerim kā paketes un ka Å”ie ziņojumi tiek nolasÄ«ti no brokera secÄ«gos blokos, izmantojot nulles kopija operācijas (operācijas, kuru laikā netiek veikts datu kopÄ“Å”anas uzdevums no vienas atmiņas apgabala uz citu). Pēdējais ir liels veiktspējas un resursu pieaugums, un tas ir iespējams, tikai izmantojot pamatā esoÅ”o žurnāla datu struktÅ«ru, kas nosaka nodalÄ«juma shēmu.

Kafka klasterÄ« ir iespējama daudz labāka veiktspēja nekā ar vienu Kafka brokeri, jo tēmu nodalÄ«jumi var tikt mērogoti daudzās atseviŔķās iekārtās.

Rezultāti

Å ajā nodaļā mēs apskatÄ«jām, kā Kafka arhitektÅ«ra pārdomā attiecÄ«bas starp klientiem un brokeriem, lai nodroÅ”inātu neticami stabilu ziņojumapmaiņas cauruļvadu ar daudzkārt lielāku caurlaidspēju nekā parastajam ziņojumu starpniekam. Mēs esam apsprieduÅ”i funkcionalitāti, ko tā izmanto, lai to panāktu, un Ä«si apskatÄ«juÅ”i lietojumprogrammu arhitektÅ«ru, kas nodroÅ”ina Å”o funkcionalitāti. Nākamajā nodaļā mēs apskatÄ«sim izplatÄ«tākās problēmas, kas jāatrisina uz ziņojumapmaiņu balstÄ«tām lietojumprogrammām, un apspriedÄ«sim to risināŔanas stratēģijas. Mēs beigsim nodaļu, izklāstot, kā runāt par ziņojumapmaiņas tehnoloÄ£ijām kopumā, lai jÅ«s varētu novērtēt to piemērotÄ«bu jÅ«su lietoÅ”anas gadÄ«jumiem.

IepriekŔējā tulkotā daļa: Izpratne par ziņojumu brokeriem. Ziņojumapmaiņas mehānikas apgÅ«Å”ana, izmantojot ActiveMQ un Kafka. 1. nodaļa

Tulkojums veikts: tele.gg/middle_java

Lai varētu turpināt ...

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai Kafka tiek izmantota jūsu organizācijā?

  • Jā

  • Nē

  • IepriekÅ” lietots, tagad nē

  • Plānojam izmantot

Nobalsoja 38 lietotāji. 8 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru