Sõnumi vahendite mõistmine. Sõnumite vahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peatükk 3. Kafka

Raamatuke tõlkimise jätk:
«Understanding Message Brokers»,
autor: Jakub Korab, väljaandja: O’Reilly Media, Inc., väljaandmise kuupäev: juuni 2017, ISBN: 9781492049296.

Eelmine tõlgitud osa: Sõnumi vahendite mõistmine. Sõnumite vahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peatükk 1. Sissejuhatus

PEATÜKK 3

Kafka

Kafka loodi LinkedInis, et ületada mõningaid traditsiooniliste sõnumite edastamise piire ja vältida vajadust konfigureerida erinevaid sõnumite edastamise vahendeid erinevatele 'punkt-punkt' interaktsioonidele, nagu on kirjeldatud selles raamatus peatükis 'Vertikaalne ja horisontaalne skaleerimine' leheküljel 28. LinkedInis põhines kasutusstsenaarium peamiselt väga suurte andmehulkade ühesuunalisel omastamisel, nagu lehtede klikkide ja logide eemaldamine, samas lubades mitme süsteemi samaaegset andmete kasutamist, mõjutamata tootjate või teiste tarbijate jõudlust. Tegelikult on Kafka olemasolu põhjus sellise sõnumite vahetamise arhitektuuri saavutamine, nagu kirjeldab Universal Data Pipeline.

Selle lõppeesmärgi tõttu on loomulik, et tekkisid ka teised nõuded. Kafka peab:

• Oleme äärmiselt kiire
• Tagama suure ribalaiuse sõnumite töötlemisel
• Toetama 'Küürija-Tellija' ja 'Punkt-Punkt' mudeleid
• Ärge viivitage tarbijate lisamisega. Näiteks, ActiveMQ jõudlus ja järjekorrad halvenevad, kui adressaadil on liiga palju tarbijaid.
• Olge horisontaalselt skaleeritav; kui üks sõnumite vahetaja suudab sõnumeid talletada (persists) ainult ülikiirusel, siis on mõttekas ületada ühe vahetaja eksemplari piirid, et suurendada jõudlust.
• Piirake juurdepääsu sõnumite talletamisele ja uuesti väljavõtmisest.

Selle saavutamiseks on Kafka's kasutusele võetud arhitektuur, mis on ümber defineerinud klientide ja sõnumivahetuse maaklerite rollid ja kohustused. JMS-i mudel on väga maaklerikeskne, kus maakler vastutab sõnumite edastamise eest, samas kui kliendid peavad muretsema vaid sõnumite saatmise ja vastuvõtmise üle. Kafka, vastupidiselt, on klientide keskne, kus klient võtab enda kanda paljusid traditsioonilise maakleri funktsioone, nagu näiteks asjakohaste sõnumite õiglane jaotamine tarbijate vahel, saades selle eest äärmiselt kiire ja skaleeritava maakleri. Inimestele, kes on töötanud traditsiooniliste sõnumivahetussüsteemidega, nõuab töö Kafka'ga fundamentaalset muutust arusaamades.
See inseneritegevus viis loodud sõnumivahetusinfrastruktuuri, mis suudab võrreldes tavapäraste maakleritega paljude mõõtmete võrra suurendada läbilaskevõimet. Nagu me näeme, on see lähenemine seotud kompromissidega, mis tähendavad, et Kafka ei sobi teatud tüüpi koormuste ja paigaldatud tarkvara jaoks.

Ühtne sihtmärkide mudel

Kohustuste täitmiseks, nagu eespool kirjeldatud, on Kafka ühendatud "väljaande-telli" ja "punkt-punkt" sõnumivahetuse vaheline mehhanism ühe adressaadiga — teema. See tekitab segadust inimestes, kes on töötanud sõnumivahetussüsteemidega, kus sõna "teema" viitab laiemale mehhanismile, mille kaudu (teemast) lugemine ei ole usaldusväärne (on mittepüsiv). Kafka teemasi tuleks käsitleda hübriidse adressaadina, vastavalt määratlusele, mis on antud selle raamatu sissejuhatuses.

Selle peatüki ülejäänud osas, kui me ei osuta selgelt teisiti, viitab termin "teema" Kafka teemale.

Selleks, et täielikult mõista, kuidas teemad käituvad ja milliseid garantiisid nad pakuvad, peame esmalt vaatama, kuidas nad on Kafka-s rakendatud.
Igal teemal Kafka-s on oma logi.
Producers sending messages to Kafka append to this log, while consumers read from the log using pointers that continually move forward. Periodically, Kafka deletes the oldest parts of the log, regardless of whether the messages in those parts have been read or not. A central aspect of Kafka's design is that the broker does not care whether messages have been read — that is the client's responsibility.

The terms "log" and "pointer" do not appear in the Kafka documentation. These well-known terms are used here to aid understanding.

This model is fundamentally different from ActiveMQ, where messages from all queues are stored in a single log, and the broker marks messages as deleted after they have been read.
Now let's delve a bit deeper and examine the topic's log in more detail.
The Kafka log consists of several partitions (Figure 3-1). Kafka tagab igas partitsioonis ranget järjestust. See tähendab, et partitsiooni teatud järjekorras salvestatud sõnumid loetakse samas järjekorras. Iga partitsioon on ellu kutsutud ringikujulise (rolling) logifailina, mis sisaldab alamkogumi (subset) kõigist sõnumitest, mida tema tootjad teema peale saadavad. Uus teema sisaldab vaikimisi ühte partitsiooni. Partitsioonide idee on Kafka keskne mõte horisontaalsest skaleerimisest.

Figure 3-1. Kafka partitsioonid

Kui tootja saadab sõnumi Kafka teemasse, otsustab ta, millisesse partitsioonisse sõnum saata. Me käsitleme seda üksikasjalikumalt hiljem.

Sõnumite lugemine

Kliendil, kes soovib sõnumeid lugeda, on hallatav nimeline osutaja, mida nimetatakse tarbijate rühm (consumer group), mis osutab asendile (offset) sõnumis partitsioonis. Asend on suureneva numbriga positsioon, mis algab partitsiooni alguses 0-st. See tarbijate rühm, millele viidatakse API-s läbi määratletud kasutaja identifikaatori group_id, vastab ühele loogilisele tarbijale või süsteemile.

Enamik sõnumivahetussüsteeme loevad andmeid adressaadilt mitme eksemplari ja voogude kaudu paralleelsete sõnumite töötlemiseks. Seetõttu on tavaliselt palju konsuumerite eksemplare, mis jagavad sama konsuumerigruppi.

Lugemise probleem esitatakse järgmiselt:

• Teemal on mitu jaotust
• Teemat saavad korraga kasutada mitmed konsuumerigruppid
• Konsuumerigrupp võib sisaldada mitmeid eraldi eksemplare

See on mittetriviaalne probleem "palju-palju". Selleks et mõista, kuidas Kafka käsitleb suhete vahel konsuumerigruppide, konsuumerite ja jaotuste vahel, vaatame mitmeid järjest keerukamaid lugemise stsenaariume.

Konsuumerid ja konsuumerigruppid

Võtame lähtepunktiks teema, millel on üks jaotus (Figure 3-2).

Figure 3-2. Konsuumer loeb jaotusest

Kui tarbija eksemplar ühendatakse oma grupi ID-ga sellele teemale, määratakse talle lugemiseks partitsioon ja nihke positsioon selles partitsioonis. Selle nihke positsiooni seadistatakse kliendis, et see viitaks kas kõige uuemale positsioonile (kõige värskem sõnum) või kõige varasemale positsioonile (kõige vanem sõnum). Tarbija küsib (polls) sõnumeid teemalt, mis viib nende järjestikuse lugemiseni ajaloost.
Nihke positsioon kommitakse regulaarselt tagasi Kafka-sse ja salvestatakse nagu sõnumid sise-teemas _consumer_offsets. Loe sõnumid ei kustutata, erinevalt tavalisest maaklerist, ja klient võib nihke tagasi kerida (rewind), et uuesti töödelda juba vaadatud sõnumeid.

Kui teine loogiline tarbija ühendatakse, kasutades teist grupi ID-d, haldab see teist näidikut, mis ei sõltu esimesest (Figure 3-3). Seega toimib Kafka teema nagu järjekord, kus on üks tarbija ja nagu tavaline väljaande-immuunsus (pub-sub), millele on ühendatud mitu tarbijat, lisaks eelisele, et kõik sõnumid salvestatakse ja neid saab töödelda mitu korda.

Joonis 3-3. Kaks tarbijat erinevates tarbijagruppides loevad ühest partitsioonist

Tarbija grupis

Kui üks tarbijainstants loeb andmeid partitsioonist, kontrollib ta täielikult näidikut ja töötleb sõnumeid nagu eelnevas osas kirjeldatud.
Kui mitu tarbijainstantsi on sama group_id-ga topikutega ühe partitsiooniga ühendatud, antakse viimase ühendatud instantsi kontroll näidiku üle ja alates sellest hetkest hakkab see saama kõik sõnumid (Joonis 3-4).

Joonis 3-4. Kaks tarbijat samas tarbijagruppis loevad ühest partitsioonist

Seda töötlemisrežiim, kus tarbijaid on rohkem kui jaotusi, võib pidada monopoltarbimiseks. See võib olla kasulik, kui vajate oma tarbijate „aktiivset-passiivset” (või „soe-külm”) klasterdamist, kuigi mitme tarbija samal ajal töötamine („aktiivne-aktiivne” või „soe-soe”) on oluliselt tavalisem kui ooterežiimis olevad tarbijad.

Ülaltoodud sõnumite jaotuse käitumine võib olla üllatav võrreldes tavalise JMS-järjekorra käitumisega. Selles mudelis jaotatakse järjekorda saadetud sõnumid võrdselt kahe tarbija vahel.

Kõige sagedamini, kui me loome mitu tarbijate eksemplari, teeme seda kas sõnumite paralleelse töötlemise, lugemise kiirusetõusu või lugemisprotsessi vastupidavuse suurendamise nimel. Kuna andmeid võib jaotisest lugeda samaaegselt ainult üks tarbija eksemplar, siis kuidas seda Kafka-s saavutatakse?

Üks viise seda teha on kasutada ühte konsumerit, et lugeda kõiki sõnumeid ja edastada need thread pooli. Kuigi see lähenemine suurendab töötlemise läbilaskevõimet, muudab see konsumerite loogika keerukamaks ning ei aita üldse süsteemi lugemise vastupidavust parandada. Kui üks konsumeri eksemplar välja lülitatakse toitekatkestuse või sarnase sündmuse tõttu, siis lugemine peatub.

Selle probleemi kanoniline lahendus Kafkas on kasutada rohkematUmbespartitsioonide.

Partitsionimine

Partitsioonid on peamine mehhanism lugemise paralleelseteks jagamiseks ja teema skaleerimiseks ühe brokeri läbilaskevõimet ületavateks. Selle parema mõistmiseks vaatame olukorda, kus on teema, millel on kaks partitsiooni ja sellele teemale on tellinud üks konsumer (Figure 3-5).

Figure 3-5. Üks konsumer loeb mitmest partitsioonist

Selles stsenaariumis antakse konsumerile kontroll näidikute üle, mis vastavad tema group_id-le mõlemas partitsioonis, ja lugemine algab mõlemast partitsioonist.
Kui sellesse teema lisatakse sama group_id jaoks täiendav tarbija, määrab Kafka ühe partitsiooni esimeselt teisele tarbijale ümber. Pärast seda loeb iga tarbija eksemplar ühest partitsioonist teemad.Kujutis 3-6).

Selleks, et tagada sõnumite töötlemine paralleelselt 20 lõimes, vajate vähemalt 20 partitsiooni. Kui partitsioone on vähem, jäävad teil tarbijad, kellel pole midagi teha, nagu oli varem arutatud monopolide tarbijatega.

Kujutis 3-6. Kaks tarbijat samas tarbijate grupis loevad erinevatest partitsioonidest

See skeem vähendab oluliselt Kafka vahendaja töö keerukust võrreldes sõnumite jaotamisega, mis on vajalik JMS järjekorra toetamiseks. Siin ei pea muretsema järgmiste punktide pärast:

• Milline tarbija peaks saama järgmise sõnumi, lähtudes ringja (round-robin) jaotamisest, praegustest eeltäitemälude mahtudest või eelmistest sõnumitest (nagu JMS sõnumigruppide puhul).
• Millised sõnumid on saadetud millistele tarbijatele ja kas need tuleb edastada uuesti juhul, kui tekib rike.

Kõik, mida Kafka broker peab tegema, on edastada sõnumid tarbijale järjestikku, kui viimane neid küsib.

Kuid nõuded paralleelse lugemise ja ebaõnnestunud sõnumite uuesti saatmise osas ei kao kuskile - vastutus nende eest läheb lihtsalt brokerilt kliendile. See tähendab, et need tuleb teie koodis arvesse võtta.

Sõnumite edastamine

Otsus selle kohta, millisesse partitsiooni sõnum saata, lasub selle sõnumi tootjal. Kuidas see mehhanism töötab, mõistmiseks tuleb esmalt uurida, mida me tegelikult saadame.

Kui JMS-is kasutame me sõnumistruktuuri koos metainformatsiooniga (pealkirjad ja omadused) ning kehaga, mis sisaldab koormust (payload), siis Kafka sõnum on võti-väärtus paar. Sõnumi koormus saadetakse väärtusena (value). Võti, omakorda, kasutatakse peamiselt partitsioneerimise jaoks ja peab sisaldama äriloogika jaoks spetsiifilist võtit, et gruppeerida omavahel seotud sõnumid samasse partitsiooni.

II peatükis arutasime online-panuste stsenaariumi, kus seotud sündmused tuleb töötleda järjestikku ühe tarbija poolt:

1. Kasutajakonto on seadistatud.
2. Raha kantakse kontole.
3. Tehtud panus, mis tõmbab raha kontolt.

Kui iga sündmus esindab sõnumit, mis saadetakse teema, siis on loogiliseks võtmeks kasutajakonto identifikaator.
Kui sõnum saadetakse Kafka Producer API kaudu, edastatakse see partitsioneerimise funktsioonile, mis arvestab sõnumit ja hetkeolekut Kafka klastris, tagastab partitsiooni identifikaatori, kuhu sõnum tuleks saata. See funktsioon on Java's rakendatud Partitioner liidese kaudu.

See liides näeb välja järgmine:

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

Particionaatori realiseerimine, et määrata jaotust, kasutab vaikeväljana võtme hashring algoritmi (üldotstarbeline hash-algoritm võtme jaoks) või ringjätku (round-robin), kui võti ei ole määratud. See vaikeväärtus töötab suurepäraselt enamikul juhtudel. Tulevikus võiksite siiski kirjutada oma versiooni.

Oma partitsioneerimisstrateegia kirjutamine

Vaatame näidet, kus soovite saata metainfot koos sõnumi koormaga. Meie näite koormaks on juhis deposiidi tegemiseks mängukontole. Juhis on see, mida soovime tagada, et seda ei muudetaks edastamisel, ja soovime olla kindlad, et ainult usaldusväärne ülemine süsteem suudab seda juhist algatada. Sellisel juhul lepitakse saatmise ja vastuvõtmise süsteemide vahel kokku allkirja kasutamises sõnumi autentimise kontrollimiseks.
Tavalisel JMS-is määrame lihtsalt "sõnumi allkirja" omaduse ja lisame selle sõnumile. Siiski ei paku Kafka mehaanismi metainformatsiooni edastamiseks — ainult võtme ja väärtuse.

Kuna väärtus on pangaülekande koormus (bank transfer payload), mille terviklikkust soovime säilitada, ei jää meil muud valikut, kui määrata andmestruktuur, mida kasutada võtmes. Eeldades, et vajame konto identifikaatorit andmete jagamiseks, kuna kõik konto seonduvad sõnumid peavad olema töödelda järjestikuses järjekorras, mõtleme välja järgmise JSON-struktuuri:

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

Kuna allkirja väärtus varieerub koormuse järgi, ei suuda Partitioner'i vaikestrateegia usaldusväärselt rühmitada seondunud sõnumeid. Seetõttu peame kirjutama oma strateegia, mis analüüsib seda võtit ja jagab (partition) accountId väärtust.

Kafka sisaldab sõnumite kahjustuse avastamiseks kontrollsummasid ja omab täielikku turvafunktsioonide komplekti. Siiski ilmnevad mõnikord spetsiifilised tööstusnõuded, nagu eelnevalt mainitud.

Kasutaja partitsioneerimisstrateegia peab tagama, et kõik seotud sõnumid jäävad ühte partitsiooni. Kuigi see näib olevat lihtne, võib nõue keeruliseks osutuda, kuna on oluline säilitada seotud sõnumite järjekord ja kui fikseeritud on partitsioonide arv teemas.

Teema partitsioonide arv võib aja jooksul muutuda, kuna neid on võimalik lisada, kui liiklus ületab esialgsed ootused. Seega võivad sõnumite võtmed olla seotud partitsiooniga, kuhu nad algselt saadeti, viidates osale olekust, mida tuleb jaotada tootja eksemplaride vahel.

Teine aspekt, mida arvestada, on sõnumite ühtlane jaotumine partitsioonide vahel. Üldiselt ei jaotata võtmeid sõnumite vahel ühtlaselt, ja hash-funktsioonid ei garanteeri õiglast sõnumite jaotumist väikese võtmete komplekti jaoks.
Oluline on märkida, et sõltumata sellest, kuidas otsustate sõnumeid jagada, võib osade eraldaja vajada korduvat kasutamist.

Vaatame andmete replikatsiooni nõuet erinevates geograafilistes asukohtades asuvate Kafka klasterite vahel. Selleks on Kafka varustatud käsurea tööriistaga nimega MirrorMaker, mida kasutatakse sõnumite lugemiseks ühest klastrist ja nende edastamiseks teise.

MirrorMaker peab mõistma replitseeritava teema võtmeid, et säilitada suhteline järjekord sõnumite vahel, kuna selle teema partitsioonide arv võib kahes klastris erineda.

Kohandatud partitsioneerimisstrateegiaid esineb suhteliselt harva, kuna vaikimisi hashimine või tsükliline jagamine töötab enamikus stsenaariumites edukalt. Siiski, kui vajate ranget järjekorra tagamist või peate laadimistest välja tooma metaandmeid, on partitsioneerimine see, millele peaksite rohkem tähelepanu pöörama.

Kafka skaleeritavuse ja jõudluse eelised tulenevad mõnede traditsiooniliste maaklerite kohustuste edasiviimisest kliendile. Sel juhul tehakse otsus potentsiaalselt seotud sõnumite jaotamise kohta mitme samaaegselt töötava tarbija vahel.

JMS maaklerid peavad samuti nende nõuetega arvestama. Huvitav on see, et seotud sõnumite saatmise mehhanism, mis on rakendatud läbi JMS sõnumigruppide (üks kleepuva koormuse tasakaalustamise (SLB) strateegia tüüp), nõuab samuti, et saatja märkiks sõnumid kui seotud. JMS-i puhul vastutab maakler selle sõnumigruppi kuuluva seotud sõnumi saatmise eest ühe tarbija juurde paljude seast ja grupi omandiõiguse edastamise eest, kui tarbija katkeb.

Produtsendi kokkulepped

Partitsioneerimine ei ole ainus, mida tuleb arvesse võtta sõnumite saatmisel. Vaatame Java API klassi Producer meetodeid send ():

Future  send(ProducerRecord  record);
Future  send(ProducerRecord  record, Callback callback);

Tuleb kohe märkida, et mõlemad meetodid tagastavad Future, mis viitab sellele, et saatmisoperatsioon ei toimu koheselt. Tulemuseks on see, et sõnum (ProducerRecord) salvestatakse igale aktiivsele partitsioonile saatmispuppu ja edastatakse brokerile taustavoolus Kafka kliendi raamatukogus. Kuigi see teeb töötamise uskumatult kiireks, tähendab see, et kehvasti kirjutatud rakendus võib sõnumeid kaotada, kui selle protsess peatatakse.

Nagu ikka, on võimalus muuta saatmisoperatsioon usaldusväärsemaks, kuid selle arvel mõjutada jõudlust. Selle puhvri suurust saab seada nulliks ning saatva rakenduse voog peab ootama, kuni sõnumi edastamine brokerile on lõpule viidud, nagu järgneb:

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

Veel kord sõnumite lugemisest

Sõnumite lugemine toob kaasa täiendavaid keerukusi, millest tuleb arutleda. Erinevalt JMS API-st, mis võib käivitada sõnumikuulaja (message listener) sõnumi saabumisel, kasutab Consumer Kafka ainult küsitakse (polling). Vaatame lähemalt meetodit poll (), mida selleks kasutatakse:

ConsumerRecords  poll(long timeout);

Meetodi tagastatav väärtus on konteineristruktuur, mis sisaldab mitmeid objekte ConsumerRecord potentsiaalselt mitmest partitsioonist. ConsumerRecord on iseenesest võtme-väärtuse paari hoidja objekt, millel on vastavad metaandmed, näiteks partitsioon, kust see saadud on.

Kuna arutatud teises peatükis, peame pidevalt meeles pidama, mis juhtub sõnumitega pärast nende eduka või ebaeduka töötlemise, näiteks juhul kui klient ei saa sõnumit töödelda või katkestab töötamise. JMS-is käsitleti seda kinnitamisrežiimi kaudu. Broker kustutab kas edukalt töödeldud sõnumi või toimetab uuesti töötlemata või ebaõnnestunud sõnumi (eeldusel, et kasutati tehinguid).
Kafka toimib täiesti erinevalt. Sõnumeid ei kustutata brokrist pärast lugemist ja vastutus selle eest, mis juhtub tõrke korral, lasub lugemisprotsessil endal.

Kuna oleme juba öelnud, on tarbijate grupp seotud žurnali nihkega. Nihkega seotud positsioon žurnal vastab järgmisele sõnumile, mis antakse välja vastusena poll (). Ajal, mil see nihke suureneb, on lugemise jaoks määrava tähtsusega.

Tagasi eelnevalt käsitletud lugemisrežiimi juurde, koosneb sõnumi töötlemine kolmest etapist:

1. Sõnumi väljavõtmine lugemiseks.
2. Sõnumi töötlemine.
3. Sõnumi kinnitamine.

Kafka konsumeril on konfigureerimise valik enable.auto.commit. See on sageli kasutatav vaikeasetus, nagu tavaliselt juhtub seadetega, mis sisaldavad sõna "auto".

Enne Kafka 0.10 versiooni saatis klient, kes kasutas seda parameetrit, viimase loetud sõnumi nihke järgmise kutsumise ajal poll () pärast töötlemist. See tähendas, et kõik sõnumid, mis olid juba välja võetud (fetched), võidi uuesti töödelda, kui klient oli need juba töötlenud, kuid hävis ootamatult enne kutsumist. poll (). Kuna maakler ei hoia mingit seisundit selle kohta, kui mitu korda sõnumit on loetud, ei tea järgmine tarbija, kes selle sõnumi kätte saab, et midagi halba on juhtunud. See käitumine oli pseudo-tehinguline. Positiivne kinnitati ainult siis, kui sõnumit töödeldi edukalt, kuid kui klient katkestas, saatis maakler sama sõnumi teisele kliendile. Selline käitumine vastas sõnumite kohaletoimetamise garantii "vähemalt kord«.

Kafkas 0.10 muudeti kliendi koodi nii, et kinnitamine käivitati perioodiliselt klientide poolt vastavalt seadistusele auto.commit.interval.ms. See käitumine asub kuskil JMS AUTO_ACKNOWLEDGE ja DUPS_OK_ACKNOWLEDGE režiimide vahel. Automaatkomite kasutamisel võidi teadete tõenäoliselt kinnitada, sõltumata sellest, kas need oli tegelikult töödeldud - see võis juhtuda aeglase tarbija tõttu. Kui tarbija katkestas töö, tõmmati teated järgmise tarbija poolt, alustades kinnitatud positsioonist, mis võis põhjustada teate varjamise. Sellisel juhul ei kaotanud Kafka teateid, lugemisprotsess lihtsalt ei töötlenud neid.

See režiim omab samu perspektiive nagu versioonis 0.9: teated võivad olla töödeldud, kuid tõrke korral ei pruugi positsiooni kinnitada, mis võib potentsiaalselt põhjustada kahekordset saatmist. Mida rohkem teateid te tõmmate, kui poll (), seda rohkem on see probleem.

Nagu arutati jaotises 'Teadete lugemine järjekorrast' lk 21, ei ole sõnumite edastamisel süsteemis mõistet, nagu ühekordne sõnumite saatmine, kui arvesse võtta tõrkeriske.

Kafkas on kaks viisi nihke (offset) kinnitamiseks: automaatne ja käsitsi. Mõlemal juhul võivad sõnumid töötlemiseks korduvalt läbi käia, kui sõnum on töödeldud, kuid kinnitamine nurjus. Samuti saate sõnumit üldse mitte töödelda, kui kinnitamine toimus taustal ja teie kood lõpetati enne, kui see töötlemisega alustas (võib-olla Kafkas versioonis 0.9 ja vanemates versioonides).

Nihke kinnitamise protsessi käsitsi juhtimine on võimalik Kafkas kasutatavas API-s, seades parameetri enable.auto.commit false väärtuseks ja kutsudes selgelt välja ühe järgmistest meetoditest:

void commitSync();
void commitAsync();

Kui soovite sõnumit töödelda „vähemalt üks kord“, peate kinnitama nihke käepideme koha pealt commitSync (), täites selle käsu kohe pärast sõnumite töötlemist.

Need meetodid ei võimalda sõnumeid kinnitada (tunnustamine) enne nende töötlemist, kuid nad ei tee midagi, et vältida võimalikke topelt töötlemisi, samas luues illusiooni tehingulisusest. Kafkas pole tehinguid. Kliendil puudub võimalus teha järgmist:

• Automaatne ebaõnnestunud sõnumi tagasikerimine. Tarbijad peavad ise käsitlema erandeid, mis tulenevad probleemsetest koormatest ja tagasiside katkestustest, kuna nad ei saa toetuda sõnumite edastamise kordamisele vahendaja poolt.
• Saata sõnumeid mitmesse teema ühes aatomaaroperatsioonis. Nagu me varsti näeme, võib erinevate teemade ja parameetrite üle kontroll olla erinevates masinates Kafka klastris, mis ei koordineeri tehinguid saatmisel. Artikli kirjutamise ajaks on tehtud teatud töö selle võimaldamiseks KIP-98 kaudu.
• Siduda ühe sõnumi lugemine ühest teemast teise sõnumi saatmisega teise teema. Jällegi, Kafka arhitektuur sõltub paljusid sõltumatutest masinatest, mis töötavad nagu üks buss, ja ei tehta mingeid katseid seda peita. Näiteks ei eksisteeri API komponente, mis võimaldaksid siduda Tarbij ja Tootja tehingus. JMS-is tagab selle objekt Seanss, millest luuakse Sõnumi tootjad ja Sõnumi tarbijad.

Kui me ei saa toetuda tehingutele, siis kuidas saame tagada semantika, mis on lähedasem traditsiooniliste sõnumivahetussüsteemide pakutavale?

Kui on oht, et tarbija nihke suurus võib suureneda enne, kui sõnum on töödeldud, näiteks tarbija rike ajal, siis ei ole tarbijal mingit viisi teada saada, kas tema tarbijagrupp on sõnumeid vahele jätnud, kui talle määratakse jaotus. Seetõttu on üheks strateegiaks nihke tagasi keeramine eelmisele positsioonile. Kafka tarbija API pakub selleks järgmisi meetodeid:

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

Meetod seek () seda saab kasutada koos meetodiga
offsetsForTimes (Map timestampsToSearch) kui soovite minna tagasi mingisse kindlasse mineviku hetke.

Implicitly, using this approach means that it is quite likely that some messages that were processed earlier will be read and processed again. To avoid this, we can use idempotent reading, as described in Chapter 4, to track previously viewed messages and exclude duplicates.

Alternatively, your consumer code can be simple if message loss or duplication is acceptable. When we consider the use cases for which Kafka is typically used, such as log event processing, metrics, click tracking, etc., we understand that losing individual messages is unlikely to have a significant impact on surrounding applications. In such cases, default values are perfectly acceptable. On the other hand, if your application needs to process payments, you must take great care with each individual message. It all comes down to context.

Isiklikud tähelepanekud näitavad, et koos sõnumite intensiivsuse kasvuega väheneb iga eraldi sõnumi väärtus. Suurehulga sõnumid muutuvad tavaliselt väärtuslikuks, kui neid vaadelda koondatud kujul.

Kõrge kättesaadavus (High Availability)

Kafkastik kõrge kättesaadavuse lähenemine erineb oluliselt ActiveMQ lähenemisest. Kafka on välja töötatud horisontaalselt skaaleeritavate klastrite põhjal, kus kõik maakleri eksemplarid aktsepteerivad ja jagavad sõnumeid samaaegselt.

Kafka klaster koosneb mitmest maakleri eksemplarist, mis töötavad erinevates serverites. Kafka on projekteeritud töötama tavalisel iseseisval riistvaral, kus igal sõlmel on oma eraldatud andmemälu. Võrgu kaudu talletatavate andmete (SAN) kasutamine ei ole soovitatav, kuna mitu arvutuslikku sõlme võivad konkureerida ajaintervallide pärast ja tekitada konflikte.Ali

Kafka on pidevalt sisse lülitatud süsteem. Paljud suured Kafka kasutajad ei sulge oma klastreid ning tarkvara tagab alati uuenduse järjestikku taaskäivitades. See saavutatakse, garanteerides ühilduvuse varasema versiooniga sõnumite ja vahetuste vahel brokerite.

Brokerid on ühendatud serverite klastriga ZooKeeper, mis toimib konfiguratsioonide registrina ja mida kasutatakse iga brokera rollide koordineerimiseks. ZooKeeper on ise jaotatud süsteem, mis tagab kõrge saadavuse teabe replikatsiooni kaudu kvorumite loomisega. kvorum.

Baastasemel luuakse teema Kafka klastris järgmiste omadustega:

• Partitsioonide arv. Nagu eelnevalt mainitud, sõltub siin kasutatav täpne väärtus soovitud paralleelse lugemise tasemest.
• Replikatsiooni koefitsient määrab, kui palju brokera eksemplare klastris peavad selle partitsiooni logisid sisaldama.

Kasutades ZooKeepers'i koordineerimiseks, püüab Kafka õiglaselt jaotada uusi partitioone klastris olevate brokerite vahel. Seda teeb üks eksemplar, mis täidab Kontrolleri rolli.

käitamisel iga teema partitsiooni jaoks Kontroller määra brokerile rollid juhi (leader, master, juht) ja järgijad (followers, slaves, alamad). Broker, kes toimib juhi rollis antud partitsioonile, vastutab kõigi sõnumite vastuvõtmise eest, mida produtsendid talle saadavad, ja sõnumite levitamise eest tarbijatele. Kui sõnumid saadetakse teema partitsiooni, kopeeritakse need kõikidele brokeri sõlmedele, mis tegutseb selle partitsiooni järgijatena. Iga sõlm, millel on partitsiooni kuurnalud, nimetatakse kopeerimiseks. Broker võib olla juhi rollis mõnedele partitsioonidele ja järgija rollis teistele.

Järgija, kellel on kõik sõnumid, mis on juhi juures salvestatud, kutsutakse sünkroniseeritud kopeerimiseks (sünkroonse olekuga koopiaga, in-sync replica). Kui partitsiooni juhtiv broker väljub, võib iga broker, kellel on selle partitsiooni suhtes ajakohane või sünkroonne olek, võtta juhtrolli. See on uskumatult vastupidav disain.

ProProduceri konfiguratsiooni osana on parameeter acks, mis määrab, kui palju koopiaid peab sõnumi vastuvõtu kinnitama (acknowledge), enne kui rakenduse voog jätkab saatmist: 0, 1 või kõik. Kui väärtus on määratud all, saadab juht sõnumi saamisel kinnituse (confirmation) tagasi producerile, kui ta on saanud kinnituse (acknowledgements) mitmelt koopialt (sealhulgas endalt), mis on määratud teema min.insync.replicas (vaikimisi 1). Kui sõnumi edastamine ei õnnestu, kutsun producer rakenduses esile erandi (NotEnoughReplicas või NotEnoughReplicasAfterAppend).

Tüüpilises konfiguratsioonis luuakse teema kopeerimisteguri 3 (1 juht, 2 järgijat iga partitsiooni jaoks) ja parameetrit min.insync.replicas seadistatakse väärtuseks 2. Sellisel juhul lubab klaster, et üks teema partitsiooni haldav broker võib välja lülituda ilma, et see mõjutaks kliendi rakendusi.

See viib meid tagasi juba tuttava kompromissi juurde tootlikkuse ja usaldusväärsuse vahel. Replikatsioon toimub täiendava kinnitusajaga (acknowledgments) järgijatelt. Kuigi kuna see toimub paralleelselt, on replikatsioon, vähemalt kolme sõlmega, sama tootlik nagu kahega (märkamata võrgu ribalaiuse suurenemist).

Kasutades seda replikatsiooni skeemi, väldib Kafka osavalt vajadust tagada iga sõnumi füüsiline salvestamine ketasse toimingu kaudu sync (). Iga sõnum, mille tootja saadab, salvestatakse partiilugejatesse, kuid nagu arutati peatükis 2, toimub algne salvestamine operatsioonisüsteemi puhverisse. Kui see sõnum on replikatsioonitud teisele Kafka eksemplarile ja asub selle mälus, ei tähenda liidri kaotus, et sõnum ise on kadunud — selle võib enda peale võtta sünkroonitud replikatsioon.
Omandamisest loobumine operatsiooni täitmise vajadusest sync () tähendab, et Kafka saab sõnumeid vastu võtta kiirusel, millega ta suudab neid mällu kirjutada. Ja vastupidi, mida kauem saab vältida mälu kirjutamist kettale, seda parem. Seetõttu ei ole haruldane, et Kafka vahendajatele eraldatakse 64 GB mälu või rohkem. Selline mälu kasutamine tähendab, et üks Kafka eksemplar suudab töötada kiirusel, mis on mitmeid tuhandeid kordi kiirem kui traditsiooniline sõnumite vahendaja.

Kafka saab ka seadistada operatsiooni rakendamiseks sync () sõnumipakettide juurde. Kuna kõik Kafka puhul on suunatud pakettide töötlemisele, töötab see paljude kasutusjuhtumite puhul tõeliselt hästi ja on kasulik tööriist kasutajatele, kes nõuavad väga tugevaid garantiisid. Suurem osa Kafka puhtast jõudlusest on seotud sõnumitega, mis saadetakse maaklerile pakettide kujul, ja nende sõnumite lugemisega maaklerist järjestikeste plokkidena abil zero-copy operatsioonide (operatsioonide, mille käigus andmete kopeerimise ülesanne ei toimu). Viimane on suur võit jõudluse ja ressursside osas ning on võimalik ainult tänu aluseks olevale logistruktuurile, mis määratleb partitsiooni skeemi.

Kafka klaster pakub palju kõrgemat jõudlust kui üksik Kafka maakler, kuna teema partitsioonid võivad horisontaalselt skaleeruda paljudele eraldi masinatele.

Kokkuvõte

Selles peatükis käsitlesime, kuidas Kafka arhitektuur ümber mõtestab suhete loomist klientide ja vahendajate vahel, et tagada uskumatult usaldusväärne sõnumivahetuse voog, mille läbilaskevõime on palju suurem kui tavalise sõnumivahendaja oma. Arutasime funktsionaalsust, mida see selle eesmärgi saavutamiseks kasutab, ja vaatasime üle rakenduste arhitektuuri, mis seda funktsionaalsust pakub. Järgmises peatükis käsitleme ühistest probleemidest, millega sõnumivahetuspõhised rakendused tegelevad, ja arutame nende lahendamise strateegiaid. Lõpetame peatüki, sketchides, kuidas mõelda sõnumivahetustehnoloogiatele laiemalt, et saaksite hinnata nende sobivust teie kasutusjuhtumite jaoks.

Eelmine tõlgitud osa: Sõnumite vahendajate mõistmine. Sõnumite vahetuse mehhanika uurimine ActiveMQ ja Kafka abil. Peatükk 1.

Tõlge on tehtud: tele.gg/middle_java

Jätkub…

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas teie organisatsioonis kasutatakse Kafka't?

• Jah

• Ei

• Kasutati varem, praegu mitte

• Plaanime kasutada

Hääletas 38 kasutajat. 8 kasutajat jäid erapooletuks.

Allikas: habr.com