Sõnumivahetuse brokerite mõistmine. Sõnumivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peatükk 3. Kafka

Raamatukese tõlke jätkamine:
«Sõnumite vahendite mõistmine»
autor: Jakub Korab, kirjastus: O’Reilly Media, Inc., väljaandmise kuupäev: juuni 2017, ISBN: 9781492049296.

Eelmine tõlgitud osa: Sõnumite 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 traditsiooniliste sõnumite vahendite mõningaid piiranguid ja vältida vajadust seadistada mitmeid sõnumite vahendeid erinevate „punkt-punkt” interaktsioonide jaoks, nagu on kirjeldatud selles raamatus jaotises „Vertikaalne ja horisontaalne skaleerimine” leheküljel 28. LinkedInis põhines kasutusstsenaarium enim ühesuunalisel andmete kogumisel tohututes kogustes, nagu klikkide arvukus lehtedel ja juurdepääsupäevikud, võimaldades samas samaaegset juurdepääsu nendele andmetele mitmetele süsteemidele, mõjutamata tootjate või teiste tarbijate jõudlust. Tegelikult on Kafka olemasolu põhjus luua selline sõnumitevahetuse arhitektuur, nagu seda kirjeldab Universal Data Pipeline.

Arvesse võttes seda lõppeesmärki, on loomulik, et tekivad ka teised nõuded. Kafka peab:

• Olema äärmiselt kiire
• Pakuma suurt läbilaskvust sõnumite töötlemisel
• Toetama „Külastaja-Tellija” ja „Punkt-Punkt” mudeleid
• Ei tohi aeglustuda tarbijate lisamisel. Näiteks ActiveMQ puhul halveneb nii jõudlus kui ka järjekorrad ja teema tarbija arvu suurenedes.
• Olema horisontaalselt skaleeritav; kui üks vahend, mis säilitab sõnumeid, saab seda teha ainult maksimaalse ketta kiirusel, on mõistlik suurendada tootlikkust, ületades ühe vahendi eksemplari.
• Piirama juurdepääsu sõnumite salvestamisele ja uuesti väljavõttele

Selle saavutamiseks rakendas Kafka arhitektuuri, mis defineeris ümber klientide ja sõnumivahetuse maaklerite rollid ja kohustused. JMS mudel keskendub väga maaklerile, kus maakler vastutab sõnumite levitamise eest, samal ajal kui kliendid peavad muretsema ainult sõnumite saatmise ja vastuvõtmise pärast. Kafka, seevastu, on suunatud kliendile, kus klient võtab endale palju traditsioonilise maakleri funktsioone, nagu vastavate sõnumite õiglane jaotamine tarbijate seas, olles vastutasuks erakordselt kiire ja skaleeritav maakler. Inimestele, kes on töötanud traditsiooniliste sõnumivahetussüsteemidega, nõuab töötamine Kafkaga põhimõttelisi muudatusi vaates.
See insenerisuund on viinud sõnumivahetuse infrastruktuuri loomisele, mis suudab oluliselt suurendada läbilaskevõimet võrreldes tavalise maakleriga. Nagu me näeme, kaasneb selle lähenemisega kompromisse, mis tähendavad, et Kafka ei sobi teatud tüüpi koormuste ja paigaldatud tarkvara jaoks.

Ühtne sihtmoodi mudel

Nende nõuete täitmiseks on Kafka ühendanud «avalik-üldine» ja «punkt-punkt» tüüpi sõnumivahetuse ühe sihtmoodi - teema. See segadusse ajab inimesi, kes on töötanud sõnumivahetussüsteemidega, kus sõna «teema» viitab laiale levitusmehhanismile, kust (teemast) lugemine ei ole usaldusväärne (is nondurable). Kafka teemasid tuleks pidada hübriidiks sihtmoodiks vastavalt määritusele, mis on antud selle raamatu sissejuhatuses.

Selle peatüki ülejäänud osas, kui me ei näita selgelt teisiti, viitab termin «teema» Kafka teemale.

Kuna mõista täielikult, kuidas teemad käituvad ja milliseid garantiisid nad pakuvad, peame esmalt uurima, kuidas need on Kafka-s rakendatud.
Igal Kafkas teemal on oma žurnal.
Producentid, kes saadavad sõnumeid Kafka'sse, kirjutavad sellesse ajakirja, samas kui tarbijad loevad ajakirjast andmeid, kasutades pidevalt edenevaid näitajaid. Aeg-ajalt kustutab Kafka ajakirjast vanimad osad, sõltumata sellest, kas nendes osades olnud sõnumid on loetud või mitte. Kafka disaini keskne põhimõte on see, et broker ei muretse selle pärast, kas sõnumid on loetud või mitte — see on kliendi vastutus.

Termineid „ajakirj“ ja „näitaja“ ei leidu Kafka dokumentatsioonis. Need tuntud terminid on siin kasutusel mõistmise lihtsustamiseks.

See mudel erineb täielikult ActiveMQ-st, kus kõikide järjekordade sõnumid talletatakse ühes ajakirjas, ja broker märgib sõnumid eemaldatuks pärast nende lugemist.
Lähme nüüd sügavamale ja vaatame teema ajakirja lähemalt.
Kafka ajakiri koosneb mitmest jaotusest (Figure 3-1). Kafka tagab rangelt järjestatud info igas jaotuses. See tähendab, et jaotusse kirjutatud sõnumid loetakse samas järjestuses. Iga jaotus on realiseeritud tsüklilise (rolling) ajakirjafailina, mis sisaldab osalust (subset) kõigist sõnumitest, mis on saadetud teema poolt tema producentide poolt. Luues teema, sisaldab see vaikimisi ühte jaotust. Jaotuste idee on Kafka keskne idee horisontaalse skaleerimise jaoks.

Figure 3-1. Kafka jaotused

Kui producent saadab sõnumi Kafka teemale, otsustab ta, millisesse jaotusse sõnumi saata. Käsitleme seda hiljem lähemalt.

Sõnumite lugemine

Tarbijakliendi, kes soovib sõnumeid lugeda, haldab nimeline näitaja, mida nimetatakse tarbijate grupiks (consumer group), mis osutab sõnumi nihkele (offset) jaotuses. Nihke positsioon on kasvava numbriga, mis algab 0-st jaotuse alguses. See tarbijate grupp, mida API-s viidatakse määratud kasutaja kindla identifikaatori group_id kaudu, vastab ühele loogilisele tarbijale või süsteemile..

Enamik sõnumivahetussüsteeme loevad andmeid saajast mitme eksemplari ja voolu kaudu sõnumite paralleelseks töötlemiseks. Seega on tavaliselt palju tarbijate eksemplare, kes jagavad ühte ja sama tarbijate gruppi.

Lugeprobleemi saab esitada järgmiselt:

• Teemal on mitu partisiooni
• Teemat võib korraga kasutada mitu tarbija-group'i
• Tarbija-group'il võib olla mitu eraldi eksemplari

See on keeruline "palju-palju" probleem. Et mõista, kuidas Kafka haldab suhete vahel tarbijate group'ide, tarbija eksemplaride ja partisioonide vahel, vaatame mitmeid järjest keerukamaid lugemisstsenaariume.

Tarbija ja tarbija-grupid

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

Figure 3-2. Tarbija loeb partisjonist

Kui tarbija eksemplar, millel on oma group_id, ühineb selle teemaga, määratakse talle lugemiseks partisjon ja selle partisjoni sees asuv offset. Selle offset'i asukoht konfigureeritakse kliendis, kas pointerina kõige uuemale positsioonile (uusim sõnum) või kõige varasemale positsioonile (vanim sõnum). Tarbija küsib (polls) sõnumeid teemast, mis viib nende järjestikusele lugemisele logis.
Offset'i positsioon kompaktitakse regulaarselt tagasi Kafka-sse ja hoitakse sees, nagu sõnumid sisemises teemas _consumer_offsets. Loetud sõnumid ei kustutata, erinevalt tavalistest maakleritest, ja klient võib offset'i tagasi kerida (rewind), et uuesti töödelda juba vaadatud sõnumeid.

Kui ühendub teine loogiline tarbija, kasutades teist group_id, haldab ta teist viit, mis ei sõltu esimesest (Figure 3-3). Seega toimib Kafka teema nagu Queue, kus on üks tarbija ja, nagu tavaline teema publisher-subscriber (pub-sub), millele on liitunud mitu tarbijat, lisaks sellele, et kõik sõnumid hoitakse alles ja neid saab korduvalt töödelda.

Figure 3-3. Kaks tarbijat erinevates tarbija gruppides loevad ühest partisjonist

Tarbija-grupi tarbijad

Kui üks tarbija eksemplar loeb andmeid partisjonist, kontrollib ta täielikult viidatud ja töötleb sõnumeid, nagu eelmisest osast kirjeldatud.
Kui mitu consumer'i eksemplari on ühendatud sama group_id-ga teema ühe partitsiooniga, siis viimasena ühendatud eksemplar saab kontrolli näidiku üle ja hakkab sellest hetkest saama kõiki sõnumeid (Joonis 3-4).

Joonis 3-4. Kaks consumer'it samas consumerite grupis loevad ühest partitsioonist

Seda töötlusrežiimi, kus consumerite eksemplaride arv ületab partitsioonide arvu, võib käsitleda monopoolse tarbijana. See võib olla kasulik, kui vajate oma consumerite eksemplaride "aktiivne-passiivne" (või "kuum-soe") klasterdamist, kuigi mitu consumer'it paralleelselt töötades ("aktiivne-aktiivne" või "kuum-kuum") on palju tüüpsem kui ootavad consumer'id.

Ülaltoodud sõnumite jaotuse käitumine võib olla üllatav võrreldes tavalise JMS-i järjekorra käitumisega. Selles mudelis jaotatakse järjekorras saadetud sõnumid ühtlaselt kahe consumer'i vahel.

Kõige sagedamini, kui me loome mitu consumer'i eksemplari, teeme seda kas sõnumite paralleelseks töötlemiseks, lugemise kiirusel või lugemisprotsessi usaldusväärsuse tõstmiseks. Kuna partitsioonist saab samal ajal andmeid lugeda vaid üks consumer'i eksemplar, siis kuidas seda saavutatakse Kafka-s?

Üks viis seda teha on kasutada ühte consumer'i eksemplari, et lugeda kõik sõnumid ja edastada need lõime basseini. Kuigi see lähenemine suurendab töötlemise läbilaskevõimet, suurendab see consumer'i loogika keerukust ja ei tõsta lugemisprotsessi süsteemi usaldusväärsust. Kui üks consumer'i eksemplar lülitub välja elektrikatkestuse või sarnase sündmuse tõttu, siis lugemine peatub.

Klassikaline viis selle probleemi lahendamiseks Kafka-s on kasutada rohkemOpartitsioone.

Partitsioneerimine

Partitsioonid on peamine mehhanism lugemise paralleelseks ja teema skaleerimiseks ületama ühe brokeri läbilaskevõimet. Selle parema mõistmise jaoks vaatame olukorda, kus on teema, millel on kaks partitsiooni ja millele on registreeritud üks consumer (Joonis 3-5).

Joonis 3-5. Üks tarbija loeb mitmest partitsioonist

Selles stsenaariumis antakse tarbijale kontroll näidikute üle, mis vastavad tema group_id-le mõlemal partitsioonil, ning alustatakse sõnumite lugemist mõlemast partitsioonist.
Kui sellele teemadele lisatakse täiendav tarbija sama group_id jaoks, siis Kafka eraldab (reallocate) ühe partitsiooni esimeselt teisele tarbijale. Pärast seda loeb iga tarbija eksemplar ühest partitsioonist teemat (Joonis 3-6).

Sõnumite paralleelse töötlemise tagamiseks 20 lõime kaudu on vaja vähemalt 20 partitsiooni. Kui partitsioone on vähem, jäävad teil tarbijad, kellel ei ole millegagi töötada, nagu eelnevalt arutatud monopolide tarbijate puhul.

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

See skeem vähendab oluliselt Kafka brokri töö keerukust võrreldes sõnumite jaotamisega, mis on vajalik JMS-i järjekorra toetamiseks. Siin ei ole vaja muretseda järgmiste asjade pärast:

• Milline tarbija peaks saama järgmise sõnumi, lähtudes ringikujulisest (round-robin) jaotamisest, hetke eeltäite puhvrite mahust või eelmistest sõnumitest (nagu JMS sõnumigruppide puhul).
• Millised sõnumid on saadetud millistele tarbijatele ja kas need tuleks ebaõnnestumise korral uuesti edastada.

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

Siiski ei kao nõuded lugemise ja ebaõnnestunud sõnumite uuesti edastamise paralleelseks muutmiseks kuhugi — vastutus nende eest liigub lihtsalt brokkerilt kliendile. See tähendab, et need peavad olema teie koodis arvesse võetud.

Sõnumite saatmine

Otsus, millisesse partitsiooni sõnum saata, on selle sõnumi tootja vastutus. Selle mehhanismi mõistmiseks tuleks esmalt vaadata, mida me tegelikult saadame.

Kui JMS-is kasutame me sõnumistruktuuri, millel on metaandmed (pealkirjad ja omadused) ja keha, mis sisaldab kasulikku koormust (payload), siis Kafka sõnum on võti-väärtus paar. Sõnumi kasulik koormus saadetakse väärtusena (value). Ahi, vastupidi, kasutatakse peamiselt jaotamiseks ning see peab sisaldama äri-loogikast spetsiifilist võtit, et paigutada seotud sõnumid samasse jaotusse.

Jaotises 2 arutasime online-kihlvedude stsenaariumi, kus seotud sündmusi peab töötlema järjestikku üks tarbija:

1. Kasutaja konto on seadistatud.
2. Raha kantakse kontole.
3. Kihlveo panus, mis võtab raha kontolt.

Kui iga sündmus on sõnum, mis saadetakse teema, siis antud juhul on loomulikuks võtmeiks konto identifikaator.
Kui sõnum saadetakse kasutades Kafka tootja API-d, edastatakse see jaotamisfunktsioonile, mis, võttes arvesse sõnumit ja hetke Kafka klastrit, tagastab jaotuse identifikaatori, kuhu sõnum tuleks saata. See funktsioon on Java's realiseeritud 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);
}

Partitsoleerimise realiseerimine kasutab vaikimisi võtme räsimise algoritmi (üldotstarbeline räsimise algoritm võtme üle) või ümmargust välja, kui võti pole määratud. See vaikeväärtus töötab enamikes juhtudel hästi. Siiski, tulevikus võite soovida kirjutada oma.

Oma jaotamisstrateegia kirjutamine

Vaatame näidet, kus soovite saata metaandmeid koos sõnumi kasuliku koormusega. Meie näites on kasulik koormus juhis deposiidi tegemiseks mängukontole. Juhis on see, mida me soovime garanteerida, et ei muudetaks edastamise ajal ja soovime olla kindlad, et ainult usaldusväärne üleolev süsteem saab selle juhise algatada. Sellisel juhul leppivad saatja ja vastuvõtja süsteem kokku allkirja kasutamises sõnumi autentimise kontrollimiseks.
Tavalises JMS-is määrame lihtsalt „sõnumi allkirja“ omaduse ja lisame selle sõnumile. Küll aga ei paku Kafka meile mehhanismi metaandmete edastamiseks — ainult võti ja väärtus.

Kuna väärtus on pankade ülekande koormus (bank transfer payload), mille terviklikkust me soovime säilitada, ei jää meil muud valikut, kui määrata andmestruktuur, mida kasutusele võtta võtmes. Eeldades, et meil on vaja kontonumbrit partitsioneerimiseks, sest kõik sõnumid, mis on seotud kontoga, peavad olema töötlemiseks järjestatud, välja mõtleme järgmise JSON struktuuri:

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

Kuna allkirja väärtus varieerub koormuse kaupa, siis ei ole Partitioner’i vaikestrateegia usaldusväärne meetod seotud sõnumite rühmitamiseks. Seepärast peame kirjutama oma strateegia, mis analüüsib seda võtme ja jagab (partition) accountId väärtust.

Kafka sisaldab sõnumite rikutuse tuvastamiseks kontrollsummasid ja tal on täielik turvalisuse komplekt. Isegi sel juhul võivad aeg-ajalt ilmuda spetsiifilised tööstusnõuded, nagu eespool mainitud.

Kohandatud partitsioneerimisstrateegia peab garanteerima, et kõik seotud sõnumid satuvad ühte partitsiooni. Kuigi see näib olevat lihtne, võib nõue muutuda keeruliseks seoses seotud sõnumite järjestuse säilitamise olulisusega ja kui fikseeritud on partitsioonide arv teemas.

Teema partitsioonide arv võib aja jooksul muutuda, kuna neid saab juurde lisada, kui liiklus ületab algsed ootused. Seega võivad sõnumite võtmed olla seotud partitsiooniga, kuhu nad algselt saadeti, viidates osale olekust, mis peab olema jaotatud produtsentide eksemplaride vahel.

Teine tegur, mida tuleks arvesse võtta, on sõnumite jaotumise ühtlus partitsioonide vahel. Üldiselt ei jaotata võtmeid sõnumite vahel ühtlaselt ning hash-funktsioonid ei taga sõnumite õiglast jaotumist väikese võtme kogumi puhul.
Oluline on märkida, et olenemata sellest, kuidas te otsustate sõnumid jagada, tuleb võib-olla jagajat uuesti kasutada.

Vaatame andmete replikatsiooni nõuet erinevates geograafilistes kohtades asuvate Kafka klastrite vahel. Selle eesmärgi saavutamiseks on Kafka varustatud käsuridade tööriistaga nimega MirrorMaker, mis loeb sõnumeid ühest klastrist ja edastab need teise.

MirrorMaker peab mõistma replitseeritava teema võtmeid, et säilitada suhteline järjekord sõnumite vahel klastrite vahel replikatsiooni käigus, kuna selle teema partitsioonide arv ei pruugi kahes klastris ühtida.

Kohandatud partitsioneerimisstrateegiaid esineb suhteliselt harva, kuna vaikimisi kasutatav hash'imine või tsükliline jaotamine töötab enamikes stsenaariumides edukalt. Siiski, kui vajate ranged järjekorra kindlustede, või on teil vajadus kasulikest laadimistest metadatade välja tõmmata, siis on partitsioneerimine see, millele peaksite lähemalt vaatama.

Kafka skaleeritavuse ja jõudluse eelised tulenevad mõnede traditsioonilise maakleri ülesannete kandmisest kliendile. Sel juhul tehakse otsus potentsiaalselt seotud sõnumite jagamiseks mitme paralleelselt töötava tarbija vahel.

JMS maaklerid peavad samuti selliste nõuetega toime tulema. Huvi pakub, et mehhanism, mis saadab seotud sõnumeid samale tarbijale, mida rakendatakse JMS Message Groups kaudu (liik strateegiast sticky load balancing (SLB)), nõuab samuti, et saatja markeeriks sõnumid kui seotud. JMS-i korral vastutab maakler selle seotud sõnumite rühma saatmise eest ühe tarbija hulgas ja rühma omandiõiguse edastamise eest, kui tarbija tõrkus.

Tootja lepingud

Partitsioneerimine ei ole ainus, mida tuleb arvestada sõnumite saatmisel. Vaatame Java API tootja klassi send() meetodeid:

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

Oluline on kohe märkida, et mõlemad meetodid tagastavad tuleviku (Future), mis viitab sellele, et saatmisoperatsioon ei toimu kohe. Selle tulemusena salvestatakse sõnum (ProducerRecord) saatmisvahendisse iga aktiivse partitsiooni jaoks ja see edastatakse brokerile taustprotsessis Kafka kliendi teegis. Kuigi see muudab töö äärmiselt kiireks, tähendab see, et kogenematult kirjutatud rakendus võib kaotada sõnumeid, kui selle protsess peatatakse.

Nagu alati, on olemas võimalus muuta saatmisoperatsiooni usaldusväärsemaks vastavalt jõudlusele. Selle puhvri suurust saab seada väärtusele 0, ja saatva rakenduse voog peab ootama, kuni sõnumi edastamine brokerile on lõpule viidud, järgmiselt:

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

Veel kord sõnumite lugemisest

Sõnumite lugemine toob endaga kaasa täiendavaid keerukusi, millest tuleks arutleda. Erinevalt JMS API-st, mis võib käivitada sõnumi kuulaja (message listener) saabudes sõnumi, on liides Konsument Kafka ainult küsib (polling). Vaadakem lähemalt meetodit poll (), mida selle eesmärgi nimel kasutatakse:

ConsumerRecords  poll(long timeout);

Meetodi tagastatav väärtus on konteineristruktuur, mis sisaldab mitmeid objekte ConsumerRecord potentsiaalselt mitmest partitsioonist. ConsumerRecord ise on võti-väärtuspaari hoidmise objekt vastava metainformatsiooniga, näiteks partitsioon, millest see saadud on.

Nagu käesolevas peatükis arutatud, peame pidevalt meeles pidama, mis juhtub sõnumitega pärast nende eduka või ebaõnnestunud töötlemist, näiteks kui klient ei suuda sõnumit töödelda või kui ta katkestab töö. JMS-is käsitleti seda tunnustamise režiimi (acknowledgement mode) kaudu. Broker kustutab kas edukalt töödeldud sõnumi või edastab uuesti töötlemata või ebaõnnestunud sõnumi (tingimusel, et tehingud on kasutusel).
Kafka töötab täiesti erinevalt. Sõnumeid ei kustutata brokeris pärast lugemist ning vastutus selle eest, mis juhtub rikke korral, lasub lugemisprotsessil endal.

Kuidas juba mainitud, on konsumentide rühm seotud žurnali positsiooniga. See positsioon, mis on seotud selle nihkega, vastab järgmisele sõnumile, mis antakse vastuseks poll ()Lugemise juures on määrava tähtsusega aeg, mil see nihke suureneb.

Naasdes varem käsitletud lugemismudelisse, koosneb sõnumi töötlemine kolmest etapist:

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

Kafka tarbija pakub seadistuse valikut enable.auto.commit. See on sageli kasutatav vaike seadistus, nagu tavaliselt on nende seadistustega, mis sisaldavad sõna „auto”.

Enne Kafka 0.10 klient, kes kasutas seda parameetrit, saatis eelmise 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äljavõetud, võidi uuesti töödelda, kui klient oli need juba töödelnud, kuid lülitus ootamatult välja enne kutsumist. poll (). Kuna broker ei hoia mingit seisundit selle kohta, kui tihti sõnumit on loetud, ei tea järgmine tarbija, kes selle sõnumi välja tõmbab, et midagi halba on juhtunud. See käitumine oli peaaegu tehinguline. Nihke kinnitati ainult siis, kui sõnum oli edukalt töödeldud, kuid kui klient katkestati, saadeti broker sama sõnumi uuele kliendile. See käitumine vastas sõnumite kohaletoimetamise garanteeritud reeglitele „vähemalt üks kord«.

Kafkast 0.10 oli kliendi kood muudetud selliselt, et kinnitamine käivitus perioodiliselt kliendiraamatukogus, vastavalt seadistusele auto.commit.interval.ms. See käitumine asub kusagil JMS AUTO_ACKNOWLEDGE ja DUPS_OK_ACKNOWLEDGE režiimide vahel. Autokinnitatud sõnumid võidi kinnitada olenemata sellest, kas need oli tõeliselt töödeldud — see võis juhtuda aeglase tarbija puhul. Kui tarbija katkestas, tõmmati järgmise tarbija poolt sõnumid välja kinnitatud positsioonilt, mis võis põhjustada sõnumite vahelejätmise. Sellisel juhul ei kadunud Kafka sõnumeid, lugemise kood lihtsalt ei töötlenud neid.

See režiim omab samu perspektiive kui versioonis 0.9: sõnumid võivad olla töödeldud, kuid kui ilmneb rike, ei pruugi nihke kinnitamata jääda, mis potentsiaalselt võib põhjustada sääraseid kohaletoimetamisi. Mida rohkem sõnumeid te väljavõtmiseks teete, poll ()seda suurem on see probleem.

Nagu arutatud jaotises "Sõnumite lugemine järjekorrast" lk 21, ei ole sõnumite edastamisel sõnumite vahetussüsteemis sellist mõistet nagu sõnumi ühekordne edastamine, arvestades tõrke režiime.

Kafka-s on kaks viisi, kuidas fikseerida (komiteerida) nihke (offset): automaatselt ja käsitsi. Mõlemal juhul võidakse sõnumeid töödelda mitu korda, kui sõnum on töödeldud, kuid komiteerimisel esines tõrge. Samuti ei pruugi te sõnumit üldse töödelda, kui komiteerimine toimus taustal ja teie kood lõpetati enne, kui see alustas töötlemist (võimalik, et Kafka 0.9 ja varasemates versioonides).

Nihke komiteerimise protsessi käsitsi juhtimiseks saate kasutada Kafka tarbija API-d, seades parameetri enable.auto.commit väärtuseks false ja kutsudes selgelt ühte järgmistest meetoditest:

void commitSync();
void commitAsync();

Kui soovite töödelda sõnumit "vähemalt üks kord", peate käsitsi komiteerima nihke, kasutades commitSync (), täites selle käsku kohe pärast sõnumite töötlemist.

Need meetodid ei võimalda sõnumeid kinnitada (acknowledged) enne, kui need on töödeldud, kuid nad ei tee midagi ka võimaliku dubleerimise töötlemise vältimiseks, luues samal ajal tehingu mulje. Kafka-s puuduvad tehingud. Klient ei saa teha järgmist:

• Automaatselt tagastada (roll back) ebaõnnestunud sõnumit. Tarbijad peavad ise lahendama erandid, mis tulenevad probleemsetest maksetest ja tagaküljest, sest nad ei saa loota sõnumite edastamise kordamisele brokkeri kaudu.
• Saata sõnumeid mitmesse teema ühes aatomaarse operatsiooni raames. Nagu me peagi näeme, võib erinevate teemade ja partitsioonide kontroll olla erinevates masinates Kafka klastris, mis ei koordineeri tehinguid edastamisel. Selle võimaldamiseks on tehtud teatud tööd KIP-98 abil.
• Siduda ühe sõnumi lugemine ühest teemast teise sõnumi saatmisega. Jällegi sõltub Kafka arhitektuur mitmest sõltumatust masinast, mis töötavad nagu buss ja ei püüdeta seda varjata. Näiteks ei ole olemas API komponente, mis võimaldaks siduda Tarbija ja Tootja transaktsioonis. JMS-is tagab selle objekti Session., millest luuakse MessageProducers ja MessageConsumers.

Kui me ei saa tugineda tehingutele, kuidas saame tagada semantika, mis on lähedasem sellele, mida pakuvad traditsioonilised sõnumivahetussüsteemid?

Kui on tõenäosus, et tarbija offset võib suureneda enne, kui sõnum on töödeldud, näiteks tarbija tõrke korral, siis ei ole tarbijal võimalust teada, kas tema tarbijate grupp jättis sõnumid vahele, kui talle määratakse partitsioon. Sel moel on üks strateegia offset'i tagasikerimine eelmisele positsioonile. Kafka tarbija API pakub järgmisi meetodeid selleks:

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

Meetod seek() võib kasutada koos meetodiga
offsetsForTimes (Map timestampsToSearch) tagasikerimiseks mõnesse konkreetse mineviku hetke.

Mittevaikselt tähendab selle lähenemise kasutamine, et on väga tõenäoline, et mõned juba töödeldud sõnumid loetakse ja töödeldakse uuesti. Selle vältimiseks võime kasutada idempotentset lugemist, nagu kirjeldatud peatükis 4, et jälgida varem vaadatud sõnumeid ja välistada dubleeringud.

Alternatiivina võib teie tarbija kood olla lihtne, kui sõnumite kaotamine või dubleerimine on lubatav. Kui vaatame kasutusstsenaariume, mille jaoks sageli kasutatakse Kafka't, näiteks logide töötlemine, mõõdikud, klikkide jälgimine jne, mõistame, et üksikute sõnumite kaotamine ei mõjuta tõenäoliselt ümbritsevaid rakendusi oluliselt. Sellistel juhtudel on vaikeseaded täiesti vastuvõetavad. Teisest küljest, kui teie rakendus peab edastama makseid, peate hoolikalt hoolitsema iga ühe sõnumi eest. Kõik sõltub kontekstist.

Isiklikud tähelepanekud näitavad, et sõnumite intensiivsuse suurenedes väheneb iga üksiku sõnumi väärtus. Suurte mahutega sõnumid muutuvad üldiselt väärtuslikeks, kui neid vaadata agreggeeritud kujul.

Kõrge kättesaadavus (High Availability)

Kafka lähenemine kõrge kättesaadavuse osas erineb märgatavalt ActiveMQ lähenemisest. Kafka on loodud horisontaalselt skaleeritavate klastrite põhjal, kus kõik maaklerite eksemplarid aktsepteerivad ja jagavad sõnumeid samal ajal.

Kafka klaster koosneb mitmest maakleri eksemplarist, mis töötavad erinevates serverites. Kafka on loodud töötama tavalises iseseisvas riistvaras, kus igal sõlmel on oma eraldatud salvestusruum. Võrgusalvestuste (SAN) kasutamist ei soovitata, kuna mitu arvutus-sõlme võivad konkureerida salvestusaja üle ja tekitada konflikte.Okuna need võivad tekitada konflikte.

Kafka on alati töövalmis süsteem. Paljud suured Kafka kasutajad ei keera oma klastreid kunagi välja ja tarkvara tagab alati värskenduse järkjärgulise taaskäivitamise kaudu. See saavutatakse, tagades ühilduvuse varasemate versioonidega sõnumite ja maaklerite vahel.

Maaklerid on ühendatud serverite klastrisse ZooKeeperiga, mis toimib konfiguratsiooniandmete registerina ja seda kasutatakse iga maakleri rollide koordineerimiseks. ZooKeeper ise on jaotatud süsteem, mis tagab kõrge kättesaadavuse teabe replikatsiooni kaudu, luues kvora.

Algselt luuakse Kafka klastris teema järgmiste omadustega:

• Partitsioonide arv. Nagu eelnevalt arutatud, sõltub siin kasutatav täpne väärtus soovitud paralleelse lugemise tasemest.
• Replikatsiooni suhterefineerib, kui palju maakleri eksemplare klastris peavad selle partitsiooni logisid sisaldama.

ZooKeeperide abil koordineerides püüab Kafka õiglaselt jaotada uusi partitsioone klastris maaklerite vahel. Seda teeb üks eksemplar, mis täidab kontrollija rolli.

Runi ajal määratakse igale teema partitsioonile maakler Kontroller juhtroll (juht, pearoll, peaosa) ja (liider, meister, juht) järgijaid (followers, slaves, alluva). Broker, kes tegutseb liidrina antud partitsioonis, vastutab kõigi produtsentide saadetud sõnumite vastuvõtmise ja sõnumite jaotamise eest tarbijatele. Kui saadetakse sõnumeid partitsiooni teemas, replitseeritakse need kõigile brokeri sõlmedele, kes tegutsevad selle partitsiooni follower'itena. Iga sõlm, mis sisaldab partitsioonide logisid, nimetatakse replikaks. Broker võib tegutseda liidrina ühes partitsioonis ja follower'ina teistes.

Follower, kes sisaldab kõiki sõnumeid, mis on salvestatud liidri juurde, nimetatakse sünkroonseks replikaks (`in-sync replica`). Kui broker, kes tegutseb liidrina partitsioonis, lülitub välja, võib iga broker, mis on ajakohane või sünkroonse olekuga selle partitsiooni jaoks, võtta liidri rolli. See on äärmiselt vastupidav disain.

Produtsendi konfigureerimise osa on parameeter acks, mis määrab, kui palju replikasid peab kinnitama sõnumi vastuvõtmist, enne kui rakenduse voog jätkab saatmist: 0, 1 või kõik. Kui määratakse väärtus all, siis kui sõnum on saadud, saadab liider kinnituse tagasi produtsendile, niipea kui saab kinnitused mitmelt replikalt (sealhulgas endalt), mis on määratletud teema seadistuses min.insync.replicas (`vaikimisi 1`). Kui sõnumit ei õnnestu edukalt replitseerida, kutsub produtsent välja erandi rakendusele (NotEnoughReplicas või NotEnoughReplicasAfterAppend).

Tüüpilises konfiguratsioonis luuakse teema, mille replikatsioonikoefitsient on 3 (1 liider, 2 follower'it igas partitsioonis) ja parameeter min.insync.replicas seatakse väärtusele 2. Sel juhul lubab klaster, et üks brokeritest, kes haldab teema partitsiooni, võiks välja lülituda ilma, et see mõjutaks kliendirakendusi.

See viib meid juba tuttava kompromissi juurde, mille vahel on jõudlus ja usaldusväärsus. Replitseerimine toob kaasa lisakulu ooteaja kinnituste (acknowledgments) saamiseks follower'itelt. Kuigi kuna see toimub paralleelselt, on replitseerimise jõudlus vähemalt kolmel sõlmel samasugune kui kahel (ignoreerides võrgu lairiba kasutamise suurenemist).

Kasutades seda replikatsiooni skeemi, vältib Kafka oskuslikult vajadust tagada iga sõnumi füüsiline salvestamine kettale operatsiooni kaudu sync (). Iga sõnum, mille tootja saadab, salvestatakse partitsiooni logisse, kuid nagu arutatud peatükis 2, salvestatakse fail algselt operatsiooni süsteemi puhverisse. Kui see sõnum on replitseeritud teisele Kafka instantsile ja on selle mälus, ei tähenda juhi kadumine, et sõnum ise on kadunud — selle võib üle võtta sünkroonitud replikatsioon.
Vajaduse loobumine operatsiooni teostamiseks sync () tähendab, et Kafka suudab vastu võtta sõnumeid kiirusel, millega ta saab neid mälu salvestada. Ja vastupidi, mida kauem saab vältida mälu (flushing) salvestamist kettale, seda parem. Selle põhjuseks on see, et Kafka brokeritele eraldatakse sageli 64 GB või rohkem mälu. Selline mälukasutus tähendab, et üks Kafka instants suudab töötada tuhandete kordadega kiiremini kui traditsiooniline sõnumite edastaja.

Kafka saab ka seadistada rakendama operatsiooni sync () sõnumite pakettide suhtes. Kuna kõik Kafka sisult töötab pakettide ümber, töötab see tegelikult paljude kasutusstsenaariumide jaoks üsna hästi ja on kasulik tööriist kasutajatele, kes nõuavad väga tugevaid garantiisid. Suur osa Kafka puhtast tootlikkusest on seotud sõnumitega, mis saadetakse brokerile pakettidena, ja et need sõnumid loetakse brokerist järjestikuste plokkide abil zero-copy operatsioonide (operatsioonide, mille käigus ei toimu andmete kopeerimist ühest mälupiirkonnast teise). Viimane on suur võit jõudluse ja ressursside osas ning võimalik vaid tänu aluseks oleva logi andmestruktuuri kasutamisele, mis määratleb partitsiooni skeemi.

Kafka klastris on võimalik saavutada tunduvalt kõrgemat jõudlust kui ühe Kafka brokeriga, kuna teema partitsioonid saavad horisontaalselt skaleeruda paljudele eraldi masinatele.

Summary

Selles peatükis käsitleme, kuidas Kafka arhitektuur kujundab ümber kliendi ja maakleri vahelisi suhteid, et tagada uskumatult vastupidav sõnumivahetuse kanal, mille läbilaskevõime on mitu korda suurem kui tavalise sõnumiteenuse maakleri oma. Arutame funktsionaalsust, mida see eesmärgi saavutamiseks kasutab, ja vaatleme lühidalt rakenduste arhitektuuri, mis seda funktsionaalsust toetavad. Järgmises peatükis käsitleme tavatarbijate sõnumiteenuse rakenduste ees seisvaid üldisi probleeme ja arutame nende lahendamise strateegiaid. Lõpetame peatüki, käsitledes, kuidas mõelda sõnumivahetuse tehnoloogiatest üldiselt, et saaksite hinnata nende sobivust teie kasutusstsenaariumidesse.

Eelmine tõlgitud osa: Sõnumivahendite mõistmine. Teadevahetuse mehhaanika uurimine ActiveMQ ja Kafka abil. Peatükk 1

Translation completed: tele.gg/middle_java

Jätkub…

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

Kasutatakse kas Kafka teie organisatsioonis?

• Jah

• Ei

• Varem kasutati, praegu ei kasutata

• Plaanis kasutada

38 kasutajat hääletasid. 8 kasutajat hoidusid.

Allikas: habr.com