{"id":38172,"date":"2019-10-31T22:22:05","date_gmt":"2019-10-31T19:22:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\/"},"modified":"2019-10-31T22:22:05","modified_gmt":"2019-10-31T19:22:05","slug":"ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","title":{"rendered":"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Raamatukese t\u00f5lke j\u00e4tkamine:<br \/>\n\u00abS\u00f5numite vahendite m\u00f5istmine\u00bb<br \/>\nautor: Jakub Korab, kirjastus: O'Reilly Media, Inc., v\u00e4ljaandmise kuup\u00e4ev: juuni 2017, ISBN: 9781492049296.<\/p>\n<p>Eelmine t\u00f5lgitud osa: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">S\u00f5numite vahendite m\u00f5istmine. S\u00f5numite vahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 1. Sissejuhatus<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>PEAT\u00dcKK 3<\/h2>\n<p><\/p>\n<h2>Kafka<\/h2>\n<p>\nKafka loodi LinkedInis, et \u00fcletada traditsiooniliste s\u00f5numite vahendite m\u00f5ningaid piiranguid ja v\u00e4ltida vajadust seadistada mitmeid s\u00f5numite vahendeid erinevate \u201epunkt-punkt\u201d interaktsioonide jaoks, nagu on kirjeldatud selles raamatus jaotises \u201eVertikaalne ja horisontaalne skaleerimine\u201d lehek\u00fcljel 28. LinkedInis p\u00f5hines kasutusstsenaarium enim \u00fchesuunalisel andmete kogumisel tohututes kogustes, nagu klikkide arvukus lehtedel ja juurdep\u00e4\u00e4sup\u00e4evikud, v\u00f5imaldades samas samaaegset juurdep\u00e4\u00e4su nendele andmetele mitmetele s\u00fcsteemidele, m\u00f5jutamata tootjate v\u00f5i teiste tarbijate j\u00f5udlust. Tegelikult on Kafka olemasolu p\u00f5hjus luua selline s\u00f5numitevahetuse arhitektuur, nagu seda kirjeldab Universal Data Pipeline.<\/p>\n<p>Arvesse v\u00f5ttes seda l\u00f5ppeesm\u00e4rki, on loomulik, et tekivad ka teised n\u00f5uded. Kafka peab:<\/p>\n<ul>\n<li>Olema \u00e4\u00e4rmiselt kiire<\/li>\n<li>Pakuma suurt l\u00e4bilaskvust s\u00f5numite t\u00f6\u00f6tlemisel<\/li>\n<li>Toetama \u201eK\u00fclastaja-Tellija\u201d ja \u201ePunkt-Punkt\u201d mudeleid<\/li>\n<li>Ei tohi aeglustuda tarbijate lisamisel. N\u00e4iteks ActiveMQ puhul halveneb nii j\u00f5udlus kui ka j\u00e4rjekorrad ja teema tarbija arvu suurenedes.<\/li>\n<li>Olema horisontaalselt skaleeritav; kui \u00fcks vahend, mis s\u00e4ilitab s\u00f5numeid, saab seda teha ainult maksimaalse ketta kiirusel, on m\u00f5istlik suurendada tootlikkust, \u00fcletades \u00fche vahendi eksemplari.<\/li>\n<li>Piirama juurdep\u00e4\u00e4su s\u00f5numite salvestamisele ja uuesti v\u00e4ljav\u00f5ttele<\/li>\n<\/ul>\n<p>\nSelle saavutamiseks rakendas Kafka arhitektuuri, mis defineeris \u00fcmber klientide ja s\u00f5numivahetuse maaklerite rollid ja kohustused. JMS mudel keskendub v\u00e4ga maaklerile, kus maakler vastutab s\u00f5numite levitamise eest, samal ajal kui kliendid peavad muretsema ainult s\u00f5numite saatmise ja vastuv\u00f5tmise p\u00e4rast. Kafka, seevastu, on suunatud kliendile, kus klient v\u00f5tab endale palju traditsioonilise maakleri funktsioone, nagu vastavate s\u00f5numite \u00f5iglane jaotamine tarbijate seas, olles vastutasuks erakordselt kiire ja skaleeritav maakler. Inimestele, kes on t\u00f6\u00f6tanud traditsiooniliste s\u00f5numivahetuss\u00fcsteemidega, n\u00f5uab t\u00f6\u00f6tamine Kafkaga p\u00f5him\u00f5ttelisi muudatusi vaates.<br \/>\nSee insenerisuund on viinud s\u00f5numivahetuse infrastruktuuri loomisele, mis suudab oluliselt suurendada l\u00e4bilaskev\u00f5imet v\u00f5rreldes tavalise maakleriga. Nagu me n\u00e4eme, kaasneb selle l\u00e4henemisega kompromisse, mis t\u00e4hendavad, et Kafka ei sobi teatud t\u00fc\u00fcpi koormuste ja paigaldatud tarkvara jaoks.<\/p>\n<h3>\u00dchtne sihtmoodi mudel<\/h3>\n<p>\nNende n\u00f5uete t\u00e4itmiseks on Kafka \u00fchendanud \u00abavalik-\u00fcldine\u00bb ja \u00abpunkt-punkt\u00bb t\u00fc\u00fcpi s\u00f5numivahetuse \u00fche sihtmoodi - <i>teema<\/i>. See segadusse ajab inimesi, kes on t\u00f6\u00f6tanud s\u00f5numivahetuss\u00fcsteemidega, kus s\u00f5na \u00abteema\u00bb viitab laiale levitusmehhanismile, kust (teemast) lugemine ei ole usaldusv\u00e4\u00e4rne (is nondurable). Kafka teemasid tuleks pidada h\u00fcbriidiks sihtmoodiks vastavalt m\u00e4\u00e4ritusele, mis on antud selle raamatu sissejuhatuses.<\/p>\n<blockquote><p>Selle peat\u00fcki \u00fclej\u00e4\u00e4nud osas, kui me ei n\u00e4ita selgelt teisiti, viitab termin \u00abteema\u00bb Kafka teemale.<\/p><\/blockquote>\n<p>\nKuna m\u00f5ista t\u00e4ielikult, kuidas teemad k\u00e4ituvad ja milliseid garantiisid nad pakuvad, peame esmalt uurima, kuidas need on Kafka-s rakendatud.<br \/>\n<i>Igal Kafkas teemal on oma \u017eurnal.<\/i><br \/>\nProducentid, kes saadavad s\u00f5numeid Kafka'sse, kirjutavad sellesse ajakirja, samas kui tarbijad loevad ajakirjast andmeid, kasutades pidevalt edenevaid n\u00e4itajaid. Aeg-ajalt kustutab Kafka ajakirjast vanimad osad, s\u00f5ltumata sellest, kas nendes osades olnud s\u00f5numid on loetud v\u00f5i mitte. Kafka disaini keskne p\u00f5him\u00f5te on see, et broker ei muretse selle p\u00e4rast, kas s\u00f5numid on loetud v\u00f5i mitte \u2014 see on kliendi vastutus.<\/p>\n<blockquote><p>Termineid \u201eajakirj\u201c ja \u201en\u00e4itaja\u201c ei leidu <noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation.html\">Kafka dokumentatsioonis<\/a><\/noindex>. Need tuntud terminid on siin kasutusel m\u00f5istmise lihtsustamiseks.<\/p><\/blockquote>\n<p>\nSee mudel erineb t\u00e4ielikult ActiveMQ-st, kus k\u00f5ikide j\u00e4rjekordade s\u00f5numid talletatakse \u00fches ajakirjas, ja broker m\u00e4rgib s\u00f5numid eemaldatuks p\u00e4rast nende lugemist.<br \/>\nL\u00e4hme n\u00fc\u00fcd s\u00fcgavamale ja vaatame teema ajakirja l\u00e4hemalt.<br \/>\nKafka ajakiri koosneb mitmest jaotusest (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/tm\/w2\/yf\/tmw2yf3lanppqtrumxoidotplhi.png\">Figure 3-1<\/a><\/noindex>). Kafka tagab rangelt j\u00e4rjestatud info igas jaotuses. See t\u00e4hendab, et jaotusse kirjutatud s\u00f5numid loetakse samas j\u00e4rjestuses. Iga jaotus on realiseeritud ts\u00fcklilise (rolling) ajakirjafailina, mis sisaldab <i>osalust <\/i>(subset) k\u00f5igist s\u00f5numitest, mis on saadetud teema poolt tema producentide poolt. Luues teema, sisaldab see vaikimisi \u00fchte jaotust. Jaotuste idee on Kafka keskne idee horisontaalse skaleerimise jaoks.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/39f41ebcb73ec247656c0dea438158a9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 3-1. Kafka jaotused<\/i><\/p>\n<p>Kui producent saadab s\u00f5numi Kafka teemale, otsustab ta, millisesse jaotusse s\u00f5numi saata. K\u00e4sitleme seda hiljem l\u00e4hemalt.<\/p>\n<h2>S\u00f5numite lugemine<\/h2>\n<p>\nTarbijakliendi, kes soovib s\u00f5numeid lugeda, haldab nimeline n\u00e4itaja, mida nimetatakse <i>tarbijate grupiks (consumer group)<\/i>, mis osutab <i>s\u00f5numi nihkele (offset)<\/i> jaotuses. Nihke positsioon on kasvava numbriga, mis algab 0-st jaotuse alguses. See tarbijate grupp, mida API-s viidatakse m\u00e4\u00e4ratud kasutaja kindla identifikaatori group_id kaudu, vastab <i>\u00fchele loogilisele tarbijale v\u00f5i s\u00fcsteemile.<\/i>.<\/p>\n<p>Enamik s\u00f5numivahetuss\u00fcsteeme loevad andmeid saajast mitme eksemplari ja voolu kaudu s\u00f5numite paralleelseks t\u00f6\u00f6tlemiseks. Seega on tavaliselt palju tarbijate eksemplare, kes jagavad \u00fchte ja sama tarbijate gruppi.<\/p>\n<p>Lugeprobleemi saab esitada j\u00e4rgmiselt:<\/p>\n<ul>\n<li>Teemal on mitu partisiooni<\/li>\n<li>Teemat v\u00f5ib korraga kasutada mitu tarbija-group'i<\/li>\n<li>Tarbija-group'il v\u00f5ib olla mitu eraldi eksemplari<\/li>\n<\/ul>\n<p>\nSee on keeruline \"palju-palju\" probleem. Et m\u00f5ista, kuidas Kafka haldab suhete vahel tarbijate group'ide, tarbija eksemplaride ja partisioonide vahel, vaatame mitmeid j\u00e4rjest keerukamaid lugemisstsenaariume.<\/p>\n<h3>Tarbija ja tarbija-grupid<\/h3>\n<p>\nV\u00f5tame l\u00e4htepunktina teema, millel on \u00fcks partisioon (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/6z\/tz\/dh\/6ztzdhqmjweck-z15htxb2xbe28.png\">Figure 3-2<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/46c92e6bd38774dfef3be4bd198bf35d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 3-2. Tarbija loeb partisjonist<\/i><\/p>\n<p>Kui tarbija eksemplar, millel on oma group_id, \u00fchineb selle teemaga, m\u00e4\u00e4ratakse talle lugemiseks partisjon ja selle partisjoni sees asuv offset. Selle offset'i asukoht konfigureeritakse kliendis, kas pointerina k\u00f5ige uuemale positsioonile (uusim s\u00f5num) v\u00f5i k\u00f5ige varasemale positsioonile (vanim s\u00f5num). Tarbija k\u00fcsib (polls) s\u00f5numeid teemast, mis viib nende j\u00e4rjestikusele lugemisele logis.<br \/>\nOffset'i positsioon kompaktitakse regulaarselt tagasi Kafka-sse ja hoitakse sees, nagu s\u00f5numid sisemises teemas <i>_consumer_offsets<\/i>. Loetud s\u00f5numid ei kustutata, erinevalt tavalistest maakleritest, ja klient v\u00f5ib offset'i tagasi kerida (rewind), et uuesti t\u00f6\u00f6delda juba vaadatud s\u00f5numeid.<\/p>\n<p>Kui \u00fchendub teine loogiline tarbija, kasutades teist group_id, haldab ta teist viit, mis ei s\u00f5ltu esimesest (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/qe\/v1\/yk\/qev1yktga3s-g1gqlynylbe3n9w.png\">Figure 3-3<\/a><\/noindex>). Seega toimib Kafka teema nagu Queue, kus on \u00fcks tarbija ja, nagu tavaline teema publisher-subscriber (pub-sub), millele on liitunud mitu tarbijat, lisaks sellele, et k\u00f5ik s\u00f5numid hoitakse alles ja neid saab korduvalt t\u00f6\u00f6delda.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/e9e8b9063ef7367005254d36abb47f4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 3-3. Kaks tarbijat erinevates tarbija gruppides loevad \u00fchest partisjonist<\/i><\/p>\n<h3>Tarbija-grupi tarbijad<\/h3>\n<p>\nKui \u00fcks tarbija eksemplar loeb andmeid partisjonist, kontrollib ta t\u00e4ielikult viidatud ja t\u00f6\u00f6tleb s\u00f5numeid, nagu eelmisest osast kirjeldatud.<br \/>\nKui mitu consumer'i eksemplari on \u00fchendatud sama group_id-ga teema \u00fche partitsiooniga, siis viimasena \u00fchendatud eksemplar saab kontrolli n\u00e4idiku \u00fcle ja hakkab sellest hetkest saama k\u00f5iki s\u00f5numeid (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/0j\/ao\/f2\/0jaof2mdwg3cqvmwemhtxkrltuq.png\">Joonis 3-4<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/ec6af819445dad4028f65449a735ae22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 3-4. Kaks consumer'it samas consumerite grupis loevad \u00fchest partitsioonist<\/i><\/p>\n<p>Seda t\u00f6\u00f6tlusre\u017eiimi, kus consumerite eksemplaride arv \u00fcletab partitsioonide arvu, v\u00f5ib k\u00e4sitleda monopoolse tarbijana. See v\u00f5ib olla kasulik, kui vajate oma consumerite eksemplaride \"aktiivne-passiivne\" (v\u00f5i \"kuum-soe\") klasterdamist, kuigi mitu consumer'it paralleelselt t\u00f6\u00f6tades (\"aktiivne-aktiivne\" v\u00f5i \"kuum-kuum\") on palju t\u00fc\u00fcpsem kui ootavad consumer'id.<\/p>\n<blockquote><p>\u00dclaltoodud s\u00f5numite jaotuse k\u00e4itumine v\u00f5ib olla \u00fcllatav v\u00f5rreldes tavalise JMS-i j\u00e4rjekorra k\u00e4itumisega. Selles mudelis jaotatakse j\u00e4rjekorras saadetud s\u00f5numid \u00fchtlaselt kahe consumer'i vahel.<\/p><\/blockquote>\n<p>\nK\u00f5ige sagedamini, kui me loome mitu consumer'i eksemplari, teeme seda kas s\u00f5numite paralleelseks t\u00f6\u00f6tlemiseks, lugemise kiirusel v\u00f5i lugemisprotsessi usaldusv\u00e4\u00e4rsuse t\u00f5stmiseks. Kuna partitsioonist saab samal ajal andmeid lugeda vaid \u00fcks consumer'i eksemplar, siis kuidas seda saavutatakse Kafka-s?<\/p>\n<p>\u00dcks viis seda teha on kasutada \u00fchte consumer'i eksemplari, et lugeda k\u00f5ik s\u00f5numid ja edastada need l\u00f5ime basseini. Kuigi see l\u00e4henemine suurendab t\u00f6\u00f6tlemise l\u00e4bilaskev\u00f5imet, suurendab see consumer'i loogika keerukust ja ei t\u00f5sta lugemisprotsessi s\u00fcsteemi usaldusv\u00e4\u00e4rsust. Kui \u00fcks consumer'i eksemplar l\u00fclitub v\u00e4lja elektrikatkestuse v\u00f5i sarnase s\u00fcndmuse t\u00f5ttu, siis lugemine peatub.<\/p>\n<p>Klassikaline viis selle probleemi lahendamiseks Kafka-s on kasutada rohkem<i>O<\/i>partitsioone.<\/p>\n<h3>Partitsioneerimine<\/h3>\n<p>\nPartitsioonid on peamine mehhanism lugemise paralleelseks ja teema skaleerimiseks \u00fcletama \u00fche brokeri l\u00e4bilaskev\u00f5imet. Selle parema m\u00f5istmise jaoks vaatame olukorda, kus on teema, millel on kaks partitsiooni ja millele on registreeritud \u00fcks consumer (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/en\/9g\/ct\/en9gct0o017cqp8buawguwlscty.png\">Joonis 3-5<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/cc766bf69af22698aacc3f1ac70b067f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 3-5. \u00dcks tarbija loeb mitmest partitsioonist<\/i><\/p>\n<p>Selles stsenaariumis antakse tarbijale kontroll n\u00e4idikute \u00fcle, mis vastavad tema group_id-le m\u00f5lemal partitsioonil, ning alustatakse s\u00f5numite lugemist m\u00f5lemast partitsioonist.<br \/>\nKui sellele teemadele lisatakse t\u00e4iendav tarbija sama group_id jaoks, siis Kafka eraldab (reallocate) \u00fche partitsiooni esimeselt teisele tarbijale. P\u00e4rast seda loeb iga tarbija eksemplar \u00fchest partitsioonist teemat (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/8b\/a0\/um\/8ba0umn2yzr9yy3vztonhdfiub0.png\">Joonis 3-6<\/a><\/noindex>).<\/p>\n<p>S\u00f5numite paralleelse t\u00f6\u00f6tlemise tagamiseks 20 l\u00f5ime kaudu on vaja v\u00e4hemalt 20 partitsiooni. Kui partitsioone on v\u00e4hem, j\u00e4\u00e4vad teil tarbijad, kellel ei ole millegagi t\u00f6\u00f6tada, nagu eelnevalt arutatud monopolide tarbijate puhul.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numivahetuse brokerite m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/a3c4001e4a5b92d53b6f529b2633254a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Joonis 3-6. Kaks tarbijat samas tarbijate grupis loevad erinevatest partitsioonidest<\/i><\/p>\n<p>See skeem v\u00e4hendab oluliselt Kafka brokri t\u00f6\u00f6 keerukust v\u00f5rreldes s\u00f5numite jaotamisega, mis on vajalik JMS-i j\u00e4rjekorra toetamiseks. Siin ei ole vaja muretseda j\u00e4rgmiste asjade p\u00e4rast:<\/p>\n<ul>\n<li>Milline tarbija peaks saama j\u00e4rgmise s\u00f5numi, l\u00e4htudes ringikujulisest (round-robin) jaotamisest, hetke eelt\u00e4ite puhvrite mahust v\u00f5i eelmistest s\u00f5numitest (nagu JMS s\u00f5numigruppide puhul).<\/li>\n<li>Millised s\u00f5numid on saadetud millistele tarbijatele ja kas need tuleks eba\u00f5nnestumise korral uuesti edastada.<\/li>\n<\/ul>\n<p>\nK\u00f5ik, mida Kafka brokker peab tegema, on j\u00e4rjestikku edastada s\u00f5numid tarbijale, kui viimane neid k\u00fcsib.<\/p>\n<p>Siiski ei kao n\u00f5uded lugemise ja eba\u00f5nnestunud s\u00f5numite uuesti edastamise paralleelseks muutmiseks kuhugi \u2014 vastutus nende eest liigub lihtsalt brokkerilt kliendile. See t\u00e4hendab, et need peavad olema teie koodis arvesse v\u00f5etud.<\/p>\n<h2>S\u00f5numite saatmine<\/h2>\n<p>\nOtsus, millisesse partitsiooni s\u00f5num saata, on selle s\u00f5numi tootja vastutus. Selle mehhanismi m\u00f5istmiseks tuleks esmalt vaadata, mida me tegelikult saadame.<\/p>\n<p>Kui JMS-is kasutame me s\u00f5numistruktuuri, millel on metaandmed (pealkirjad ja omadused) ja keha, mis sisaldab kasulikku koormust (payload), siis Kafka s\u00f5num on <i>v\u00f5ti-v\u00e4\u00e4rtus paar<\/i>. S\u00f5numi kasulik koormus saadetakse v\u00e4\u00e4rtusena (value). Ahi, vastupidi, kasutatakse peamiselt jaotamiseks ning see peab sisaldama <i>\u00e4ri-loogikast spetsiifilist v\u00f5tit<\/i>, et paigutada seotud s\u00f5numid samasse jaotusse.<\/p>\n<p>Jaotises 2 arutasime online-kihlvedude stsenaariumi, kus seotud s\u00fcndmusi peab t\u00f6\u00f6tlema j\u00e4rjestikku \u00fcks tarbija:<\/p>\n<ol>\n<li>Kasutaja konto on seadistatud.<\/li>\n<li>Raha kantakse kontole.<\/li>\n<li>Kihlveo panus, mis v\u00f5tab raha kontolt.<\/li>\n<\/ol>\n<p>\nKui iga s\u00fcndmus on s\u00f5num, mis saadetakse teema, siis antud juhul on loomulikuks v\u00f5tmeiks konto identifikaator.<br \/>\nKui s\u00f5num saadetakse kasutades Kafka tootja API-d, edastatakse see jaotamisfunktsioonile, mis, v\u00f5ttes arvesse s\u00f5numit ja hetke Kafka klastrit, tagastab jaotuse identifikaatori, kuhu s\u00f5num tuleks saata. See funktsioon on Java's realiseeritud Partitioner liidese kaudu.<\/p>\n<p>See liides n\u00e4eb v\u00e4lja j\u00e4rgmine:<\/p>\n<pre><code class=\"java\">interface Partitioner {\n    int partition(String topic,\n        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);\n}<\/code><\/pre>\n<p>\nPartitsoleerimise realiseerimine kasutab vaikimisi v\u00f5tme r\u00e4simise algoritmi (\u00fcldotstarbeline r\u00e4simise algoritm v\u00f5tme \u00fcle) v\u00f5i \u00fcmmargust v\u00e4lja, kui v\u00f5ti pole m\u00e4\u00e4ratud. See vaikev\u00e4\u00e4rtus t\u00f6\u00f6tab enamikes juhtudel h\u00e4sti. Siiski, tulevikus v\u00f5ite soovida kirjutada oma.<\/p>\n<h3>Oma jaotamisstrateegia kirjutamine<\/h3>\n<p>\nVaatame n\u00e4idet, kus soovite saata metaandmeid koos s\u00f5numi kasuliku koormusega. Meie n\u00e4ites on kasulik koormus juhis deposiidi tegemiseks m\u00e4ngukontole. Juhis on see, mida me soovime garanteerida, et ei muudetaks edastamise ajal ja soovime olla kindlad, et ainult usaldusv\u00e4\u00e4rne \u00fcleolev s\u00fcsteem saab selle juhise algatada. Sellisel juhul leppivad saatja ja vastuv\u00f5tja s\u00fcsteem kokku allkirja kasutamises s\u00f5numi autentimise kontrollimiseks.<br \/>\nTavalises JMS-is m\u00e4\u00e4rame lihtsalt \u201es\u00f5numi allkirja\u201c omaduse ja lisame selle s\u00f5numile. K\u00fcll aga ei paku Kafka meile mehhanismi metaandmete edastamiseks \u2014 ainult v\u00f5ti ja v\u00e4\u00e4rtus.<\/p>\n<p>Kuna v\u00e4\u00e4rtus on pankade \u00fclekande koormus (bank transfer payload), mille terviklikkust me soovime s\u00e4ilitada, ei j\u00e4\u00e4 meil muud valikut, kui m\u00e4\u00e4rata andmestruktuur, mida kasutusele v\u00f5tta v\u00f5tmes. Eeldades, et meil on vaja kontonumbrit partitsioneerimiseks, sest k\u00f5ik s\u00f5numid, mis on seotud kontoga, peavad olema t\u00f6\u00f6tlemiseks j\u00e4rjestatud, v\u00e4lja m\u00f5tleme j\u00e4rgmise JSON struktuuri:<\/p>\n<pre><code class=\"json\">{\n  \"signature\": \"541661622185851c248b41bf0cea7ad0\",\n  \"accountId\": \"10007865234\"\n}<\/code><\/pre>\n<p>\nKuna allkirja v\u00e4\u00e4rtus varieerub koormuse kaupa, siis ei ole Partitioner\u2019i vaikestrateegia usaldusv\u00e4\u00e4rne meetod seotud s\u00f5numite r\u00fchmitamiseks. Seep\u00e4rast peame kirjutama oma strateegia, mis anal\u00fc\u00fcsib seda v\u00f5tme ja jagab (partition) accountId v\u00e4\u00e4rtust.<\/p>\n<blockquote><p>Kafka sisaldab s\u00f5numite rikutuse tuvastamiseks kontrollsummasid ja tal on t\u00e4ielik turvalisuse komplekt. Isegi sel juhul v\u00f5ivad aeg-ajalt ilmuda spetsiifilised t\u00f6\u00f6stusn\u00f5uded, nagu eespool mainitud.<\/p><\/blockquote>\n<p>\nKohandatud partitsioneerimisstrateegia peab garanteerima, et k\u00f5ik seotud s\u00f5numid satuvad \u00fchte partitsiooni. Kuigi see n\u00e4ib olevat lihtne, v\u00f5ib n\u00f5ue muutuda keeruliseks seoses seotud s\u00f5numite j\u00e4rjestuse s\u00e4ilitamise olulisusega ja kui fikseeritud on partitsioonide arv teemas.<\/p>\n<p>Teema partitsioonide arv v\u00f5ib aja jooksul muutuda, kuna neid saab juurde lisada, kui liiklus \u00fcletab algsed ootused. Seega v\u00f5ivad s\u00f5numite v\u00f5tmed olla seotud partitsiooniga, kuhu nad algselt saadeti, viidates osale olekust, mis peab olema jaotatud produtsentide eksemplaride vahel.<\/p>\n<p>Teine tegur, mida tuleks arvesse v\u00f5tta, on s\u00f5numite jaotumise \u00fchtlus partitsioonide vahel. \u00dcldiselt ei jaotata v\u00f5tmeid s\u00f5numite vahel \u00fchtlaselt ning hash-funktsioonid ei taga s\u00f5numite \u00f5iglast jaotumist v\u00e4ikese v\u00f5tme kogumi puhul.<br \/>\nOluline on m\u00e4rkida, et olenemata sellest, kuidas te otsustate s\u00f5numid jagada, tuleb v\u00f5ib-olla jagajat uuesti kasutada.<\/p>\n<p>Vaatame andmete replikatsiooni n\u00f5uet erinevates geograafilistes kohtades asuvate Kafka klastrite vahel. Selle eesm\u00e4rgi saavutamiseks on Kafka varustatud k\u00e4suridade t\u00f6\u00f6riistaga nimega MirrorMaker, mis loeb s\u00f5numeid \u00fchest klastrist ja edastab need teise.<\/p>\n<p>MirrorMaker peab m\u00f5istma replitseeritava teema v\u00f5tmeid, et s\u00e4ilitada suhteline j\u00e4rjekord s\u00f5numite vahel klastrite vahel replikatsiooni k\u00e4igus, kuna selle teema partitsioonide arv ei pruugi kahes klastris \u00fchtida.<\/p>\n<p>Kohandatud partitsioneerimisstrateegiaid esineb suhteliselt harva, kuna vaikimisi kasutatav hash'imine v\u00f5i ts\u00fckliline jaotamine t\u00f6\u00f6tab enamikes stsenaariumides edukalt. Siiski, kui vajate ranged j\u00e4rjekorra kindlustede, v\u00f5i on teil vajadus kasulikest laadimistest metadatade v\u00e4lja t\u00f5mmata, siis on partitsioneerimine see, millele peaksite l\u00e4hemalt vaatama.<\/p>\n<p>Kafka skaleeritavuse ja j\u00f5udluse eelised tulenevad m\u00f5nede traditsioonilise maakleri \u00fclesannete kandmisest kliendile. Sel juhul tehakse otsus potentsiaalselt seotud s\u00f5numite jagamiseks mitme paralleelselt t\u00f6\u00f6tava tarbija vahel.<\/p>\n<blockquote><p>JMS maaklerid peavad samuti selliste n\u00f5uetega toime tulema. Huvi pakub, et mehhanism, mis saadab seotud s\u00f5numeid samale tarbijale, mida rakendatakse JMS Message Groups kaudu (liik strateegiast sticky load balancing (SLB)), n\u00f5uab samuti, et saatja markeeriks s\u00f5numid kui seotud. JMS-i korral vastutab maakler selle seotud s\u00f5numite r\u00fchma saatmise eest \u00fche tarbija hulgas ja r\u00fchma omandi\u00f5iguse edastamise eest, kui tarbija t\u00f5rkus.<\/p><\/blockquote>\n<p><\/p>\n<h2>Tootja lepingud<\/h2>\n<p>\nPartitsioneerimine ei ole ainus, mida tuleb arvestada s\u00f5numite saatmisel. Vaatame Java API tootja klassi send() meetodeid:<\/p>\n<pre><code class=\"java\">Future  send(ProducerRecord  record);\nFuture  send(ProducerRecord  record, Callback callback);<\/code><\/pre>\n<p>\nOluline on kohe m\u00e4rkida, et m\u00f5lemad meetodid tagastavad tuleviku (Future), mis viitab sellele, et saatmisoperatsioon ei toimu kohe. Selle tulemusena salvestatakse s\u00f5num (ProducerRecord) saatmisvahendisse iga aktiivse partitsiooni jaoks ja see edastatakse brokerile taustprotsessis Kafka kliendi teegis. Kuigi see muudab t\u00f6\u00f6 \u00e4\u00e4rmiselt kiireks, t\u00e4hendab see, et kogenematult kirjutatud rakendus v\u00f5ib kaotada s\u00f5numeid, kui selle protsess peatatakse.<\/p>\n<p>Nagu alati, on olemas v\u00f5imalus muuta saatmisoperatsiooni usaldusv\u00e4\u00e4rsemaks vastavalt j\u00f5udlusele. Selle puhvri suurust saab seada v\u00e4\u00e4rtusele 0, ja saatva rakenduse voog peab ootama, kuni s\u00f5numi edastamine brokerile on l\u00f5pule viidud, j\u00e4rgmiselt:<\/p>\n<pre><code class=\"java\">RecordMetadata metadata = producer.send(record).get();<\/code><\/pre>\n<p><\/p>\n<h2>Veel kord s\u00f5numite lugemisest<\/h2>\n<p>\nS\u00f5numite lugemine toob endaga kaasa t\u00e4iendavaid keerukusi, millest tuleks arutleda. Erinevalt JMS API-st, mis v\u00f5ib k\u00e4ivitada s\u00f5numi kuulaja (message listener) saabudes s\u00f5numi, on liides <i>Konsument <\/i>Kafka ainult k\u00fcsib (polling). Vaadakem l\u00e4hemalt meetodit <i>poll ()<\/i>, mida selle eesm\u00e4rgi nimel kasutatakse:<\/p>\n<pre><code class=\"java\">ConsumerRecords  poll(long timeout);<\/code><\/pre>\n<p>\nMeetodi tagastatav v\u00e4\u00e4rtus on konteineristruktuur, mis sisaldab mitmeid objekte <i>ConsumerRecord <\/i>potentsiaalselt mitmest partitsioonist. <i>ConsumerRecord <\/i>ise on v\u00f5ti-v\u00e4\u00e4rtuspaari hoidmise objekt vastava metainformatsiooniga, n\u00e4iteks partitsioon, millest see saadud on.<\/p>\n<p>Nagu k\u00e4esolevas peat\u00fckis arutatud, peame pidevalt meeles pidama, mis juhtub s\u00f5numitega p\u00e4rast nende eduka v\u00f5i eba\u00f5nnestunud t\u00f6\u00f6tlemist, n\u00e4iteks kui klient ei suuda s\u00f5numit t\u00f6\u00f6delda v\u00f5i kui ta katkestab t\u00f6\u00f6. JMS-is k\u00e4sitleti seda tunnustamise re\u017eiimi (acknowledgement mode) kaudu. Broker kustutab kas edukalt t\u00f6\u00f6deldud s\u00f5numi v\u00f5i edastab uuesti t\u00f6\u00f6tlemata v\u00f5i eba\u00f5nnestunud s\u00f5numi (tingimusel, et tehingud on kasutusel). <br \/>\nKafka t\u00f6\u00f6tab t\u00e4iesti erinevalt. S\u00f5numeid ei kustutata brokeris p\u00e4rast lugemist ning vastutus selle eest, mis juhtub rikke korral, lasub lugemisprotsessil endal.<\/p>\n<p>Kuidas juba mainitud, on konsumentide r\u00fchm seotud \u017eurnali positsiooniga. See positsioon, mis on seotud selle nihkega, vastab j\u00e4rgmisele s\u00f5numile, mis antakse vastuseks <i>poll ()<\/i>Lugemise juures on m\u00e4\u00e4rava t\u00e4htsusega aeg, mil see nihke suureneb.<\/p>\n<p>Naasdes varem k\u00e4sitletud lugemismudelisse, koosneb s\u00f5numi t\u00f6\u00f6tlemine kolmest etapist:<\/p>\n<ol>\n<li>S\u00f5numi v\u00e4ljav\u00f5tmine lugemiseks.<\/li>\n<li>S\u00f5numi t\u00f6\u00f6tlemine.<\/li>\n<li>S\u00f5numi kinnitamine.<\/li>\n<\/ol>\n<p>\nKafka tarbija pakub seadistuse valikut <i>enable.auto.commit<\/i>. See on sageli kasutatav vaike seadistus, nagu tavaliselt on nende seadistustega, mis sisaldavad s\u00f5na \u201eauto\u201d.<\/p>\n<p>Enne Kafka 0.10 klient, kes kasutas seda parameetrit, saatis eelmise loetud s\u00f5numi nihke j\u00e4rgmise kutsumise ajal <i>poll ()<\/i> p\u00e4rast t\u00f6\u00f6tlemist. See t\u00e4hendas, et k\u00f5ik s\u00f5numid, mis olid juba v\u00e4ljav\u00f5etud, v\u00f5idi uuesti t\u00f6\u00f6delda, kui klient oli need juba t\u00f6\u00f6delnud, kuid l\u00fclitus ootamatult v\u00e4lja enne kutsumist. <i>poll ()<\/i>. Kuna maakler ei hoidnud mingit olekut selle kohta, mitu korda s\u00f5numit on loetud, ei tea j\u00e4rgmine tarbija, kes selle s\u00f5numi v\u00e4lja t\u00f5mbab, et midagi halba on juhtunud. See k\u00e4itumine oli pseudo-tehinguline. Nihke teostati ainult juhul, kui s\u00f5num oli edukalt t\u00f6\u00f6deldud, kuid kui klient katkestas t\u00f6\u00f6, saatis maakler sama s\u00f5numi teisele kliendile. Selline k\u00e4itumine vastas s\u00f5numite kohaletoimetamise garantiile \"<i>v\u00e4hemalt \u00fcks kord<\/i>&#171;.<\/p>\n<p>Kafkast 0.10 oli kliendi kood muudetud selliselt, et kinnitamine k\u00e4ivitus perioodiliselt kliendiraamatukogus, vastavalt seadistusele <i>auto.commit.interval.ms<\/i>. See k\u00e4itumine asub kusagil JMS AUTO_ACKNOWLEDGE ja DUPS_OK_ACKNOWLEDGE re\u017eiimide vahel. Autokinnitatud s\u00f5numid v\u00f5idi kinnitada olenemata sellest, kas need oli t\u00f5eliselt t\u00f6\u00f6deldud \u2014 see v\u00f5is juhtuda aeglase tarbija puhul. Kui tarbija katkestas, t\u00f5mmati j\u00e4rgmise tarbija poolt s\u00f5numid v\u00e4lja kinnitatud positsioonilt, mis v\u00f5is p\u00f5hjustada s\u00f5numite vahelej\u00e4tmise. Sellisel juhul ei kadunud Kafka s\u00f5numeid, lugemise kood lihtsalt ei t\u00f6\u00f6tlenud neid.<\/p>\n<p>See re\u017eiim omab samu perspektiive kui versioonis 0.9: s\u00f5numid v\u00f5ivad olla t\u00f6\u00f6deldud, kuid kui ilmneb rike, ei pruugi nihke kinnitamata j\u00e4\u00e4da, mis potentsiaalselt v\u00f5ib p\u00f5hjustada s\u00e4\u00e4raseid kohaletoimetamisi. Mida rohkem s\u00f5numeid te v\u00e4ljav\u00f5tmiseks teete, <i>poll ()<\/i>seda suurem on see probleem.<\/p>\n<p>Nagu arutatud jaotises \"S\u00f5numite lugemine j\u00e4rjekorrast\" lk 21, ei ole s\u00f5numite edastamisel s\u00f5numite vahetuss\u00fcsteemis sellist m\u00f5istet nagu s\u00f5numi \u00fchekordne edastamine, arvestades t\u00f5rke re\u017eiime.<\/p>\n<p>Kafka-s on kaks viisi, kuidas fikseerida (komiteerida) nihke (offset): automaatselt ja k\u00e4sitsi. M\u00f5lemal juhul v\u00f5idakse s\u00f5numeid t\u00f6\u00f6delda mitu korda, kui s\u00f5num on t\u00f6\u00f6deldud, kuid komiteerimisel esines t\u00f5rge. Samuti ei pruugi te s\u00f5numit \u00fcldse t\u00f6\u00f6delda, kui komiteerimine toimus taustal ja teie kood l\u00f5petati enne, kui see alustas t\u00f6\u00f6tlemist (v\u00f5imalik, et Kafka 0.9 ja varasemates versioonides).<\/p>\n<p>Nihke komiteerimise protsessi k\u00e4sitsi juhtimiseks saate kasutada Kafka tarbija API-d, seades parameetri <i>enable.auto.commit<\/i> v\u00e4\u00e4rtuseks false ja kutsudes selgelt \u00fchte j\u00e4rgmistest meetoditest:<\/p>\n<pre><code class=\"java\">void commitSync();\nvoid commitAsync();<\/code><\/pre>\n<p>\nKui soovite t\u00f6\u00f6delda s\u00f5numit \"v\u00e4hemalt \u00fcks kord\", peate k\u00e4sitsi komiteerima nihke, kasutades <i>commitSync ()<\/i>, t\u00e4ites selle k\u00e4sku kohe p\u00e4rast s\u00f5numite t\u00f6\u00f6tlemist.<\/p>\n<p>Need meetodid ei v\u00f5imalda s\u00f5numeid kinnitada (acknowledged) enne, kui need on t\u00f6\u00f6deldud, kuid nad ei tee midagi ka v\u00f5imaliku dubleerimise t\u00f6\u00f6tlemise v\u00e4ltimiseks, luues samal ajal tehingu mulje. Kafka-s puuduvad tehingud. Klient ei saa teha j\u00e4rgmist:<\/p>\n<ul>\n<li>Automaatselt tagastada (roll back) eba\u00f5nnestunud s\u00f5numit. Tarbijad peavad ise lahendama erandid, mis tulenevad probleemsetest maksetest ja tagak\u00fcljest, sest nad ei saa loota s\u00f5numite edastamise kordamisele brokkeri kaudu.<\/li>\n<li>Saata s\u00f5numeid mitmesse teema \u00fches aatomaarse operatsiooni raames. Nagu me peagi n\u00e4eme, v\u00f5ib erinevate teemade ja partitsioonide kontroll olla erinevates masinates Kafka klastris, mis ei koordineeri tehinguid edastamisel. Selle v\u00f5imaldamiseks on tehtud teatud t\u00f6\u00f6d KIP-98 abil.<\/li>\n<li>Siduda \u00fche s\u00f5numi lugemine \u00fchest teemast teise s\u00f5numi saatmisega. J\u00e4llegi s\u00f5ltub Kafka arhitektuur mitmest s\u00f5ltumatust masinast, mis t\u00f6\u00f6tavad nagu buss ja ei p\u00fc\u00fcdeta seda varjata. N\u00e4iteks ei ole olemas API komponente, mis v\u00f5imaldaks siduda <i>Tarbija <\/i>ja <i>Tootja <\/i>transaktsioonis. JMS-is tagab selle objekti <i>Session.<\/i>, millest luuakse <i>MessageProducers <\/i>ja <i>MessageConsumers<\/i>.<\/li>\n<\/ul>\n<p>\nKui me ei saa tugineda tehingutele, kuidas saame tagada semantika, mis on l\u00e4hedasem sellele, mida pakuvad traditsioonilised s\u00f5numivahetuss\u00fcsteemid?<\/p>\n<p>Kui on t\u00f5en\u00e4osus, et tarbija offset v\u00f5ib suureneda enne, kui s\u00f5num on t\u00f6\u00f6deldud, n\u00e4iteks tarbija t\u00f5rke korral, siis ei ole tarbijal v\u00f5imalust teada, kas tema tarbijate grupp j\u00e4ttis s\u00f5numid vahele, kui talle m\u00e4\u00e4ratakse partitsioon. Sel moel on \u00fcks strateegia offset'i tagasikerimine eelmisele positsioonile. Kafka tarbija API pakub j\u00e4rgmisi meetodeid selleks:<\/p>\n<pre><code class=\"java\">void seek(TopicPartition partition, long offset);\nvoid seekToBeginning(Collection  partitions);<\/code><\/pre>\n<p>\nMeetod <i>seek()<\/i> v\u00f5ib kasutada koos meetodiga <br \/>\n<i>offsetsForTimes (Map timestampsToSearch)<\/i> tagasikerimiseks m\u00f5nesse konkreetse mineviku hetke.<\/p>\n<p>Mittevaikselt t\u00e4hendab selle l\u00e4henemise kasutamine, et on v\u00e4ga t\u00f5en\u00e4oline, et m\u00f5ned juba t\u00f6\u00f6deldud s\u00f5numid loetakse ja t\u00f6\u00f6deldakse uuesti. Selle v\u00e4ltimiseks v\u00f5ime kasutada idempotentset lugemist, nagu kirjeldatud peat\u00fckis 4, et j\u00e4lgida varem vaadatud s\u00f5numeid ja v\u00e4listada dubleeringud.<\/p>\n<p>Alternatiivina v\u00f5ib teie tarbija kood olla lihtne, kui s\u00f5numite kaotamine v\u00f5i dubleerimine on lubatav. Kui vaatame kasutusstsenaariume, mille jaoks sageli kasutatakse Kafka't, n\u00e4iteks logide t\u00f6\u00f6tlemine, m\u00f5\u00f5dikud, klikkide j\u00e4lgimine jne, m\u00f5istame, et \u00fcksikute s\u00f5numite kaotamine ei m\u00f5juta t\u00f5en\u00e4oliselt \u00fcmbritsevaid rakendusi oluliselt. Sellistel juhtudel on vaikeseaded t\u00e4iesti vastuv\u00f5etavad. Teisest k\u00fcljest, kui teie rakendus peab edastama makseid, peate hoolikalt hoolitsema iga \u00fche s\u00f5numi eest. K\u00f5ik s\u00f5ltub kontekstist.<\/p>\n<p>Isiklikud t\u00e4helepanekud n\u00e4itavad, et s\u00f5numite intensiivsuse suurenedes v\u00e4heneb iga \u00fcksiku s\u00f5numi v\u00e4\u00e4rtus. Suurte mahutega s\u00f5numid muutuvad \u00fcldiselt v\u00e4\u00e4rtuslikeks, kui neid vaadata agreggeeritud kujul.<\/p>\n<h2>K\u00f5rge k\u00e4ttesaadavus (High Availability)<\/h2>\n<p>\nKafka l\u00e4henemine k\u00f5rge k\u00e4ttesaadavuse osas erineb m\u00e4rgatavalt ActiveMQ l\u00e4henemisest. Kafka on loodud horisontaalselt skaleeritavate klastrite p\u00f5hjal, kus k\u00f5ik maaklerite eksemplarid aktsepteerivad ja jagavad s\u00f5numeid samal ajal.<\/p>\n<p>Kafka klaster koosneb mitmest maakleri eksemplarist, mis t\u00f6\u00f6tavad erinevates serverites. Kafka on loodud t\u00f6\u00f6tama tavalises iseseisvas riistvaras, kus igal s\u00f5lmel on oma eraldatud salvestusruum. V\u00f5rgusalvestuste (SAN) kasutamist ei soovitata, kuna mitu arvutus-s\u00f5lme v\u00f5ivad konkureerida salvestusaja \u00fcle ja tekitada konflikte.<i>O<\/i>kuna need v\u00f5ivad tekitada konflikte.<\/p>\n<p>Kafka on <i>alati t\u00f6\u00f6valmis<\/i> s\u00fcsteem. Paljud suured Kafka kasutajad ei keera oma klastreid kunagi v\u00e4lja ja tarkvara tagab alati v\u00e4rskenduse j\u00e4rkj\u00e4rgulise taask\u00e4ivitamise kaudu. See saavutatakse, tagades \u00fchilduvuse varasemate versioonidega s\u00f5numite ja maaklerite vahel.<\/p>\n<p>Maaklerid on \u00fchendatud serverite klastrisse <noindex><a rel=\"nofollow\" href=\"http:\/\/zookeeper.apache.org\">ZooKeeperiga<\/a><\/noindex>, mis toimib konfiguratsiooniandmete registerina ja seda kasutatakse iga maakleri rollide koordineerimiseks. ZooKeeper ise on jaotatud s\u00fcsteem, mis tagab k\u00f5rge k\u00e4ttesaadavuse teabe replikatsiooni kaudu, luues <i>kvora<\/i>.<\/p>\n<p>Algselt luuakse Kafka klastris teema j\u00e4rgmiste omadustega:<\/p>\n<ul>\n<li>Partitsioonide arv. Nagu eelnevalt arutatud, s\u00f5ltub siin kasutatav t\u00e4pne v\u00e4\u00e4rtus soovitud paralleelse lugemise tasemest.<\/li>\n<li>Replikatsiooni suhterefineerib, kui palju maakleri eksemplare klastris peavad selle partitsiooni logisid sisaldama.<\/li>\n<\/ul>\n<p>\nZooKeeperide abil koordineerides p\u00fc\u00fcab Kafka \u00f5iglaselt jaotada uusi partitsioone klastris maaklerite vahel. Seda teeb \u00fcks eksemplar, mis t\u00e4idab kontrollija rolli.<\/p>\n<p>Runi ajal <i>m\u00e4\u00e4ratakse igale teema partitsioonile maakler<\/i> <i>Kontroller <\/i>juhtroll <i>(juht, pearoll, peaosa) ja <\/i>(liider, meister, juht) <i>j\u00e4rgijaid <\/i>(followers, slaves, alluva). Broker, kes tegutseb liidrina antud partitsioonis, vastutab k\u00f5igi produtsentide saadetud s\u00f5numite vastuv\u00f5tmise ja s\u00f5numite jaotamise eest tarbijatele. Kui saadetakse s\u00f5numeid partitsiooni teemas, replitseeritakse need k\u00f5igile brokeri s\u00f5lmedele, kes tegutsevad selle partitsiooni follower'itena. Iga s\u00f5lm, mis sisaldab partitsioonide logisid, nimetatakse <i>replikaks<\/i>. Broker v\u00f5ib tegutseda liidrina \u00fches partitsioonis ja follower'ina teistes.<\/p>\n<p>Follower, kes sisaldab k\u00f5iki s\u00f5numeid, mis on salvestatud liidri juurde, nimetatakse <i>s\u00fcnkroonseks replikaks<\/i> (`in-sync replica`). Kui broker, kes tegutseb liidrina partitsioonis, l\u00fclitub v\u00e4lja, v\u00f5ib iga broker, mis on ajakohane v\u00f5i s\u00fcnkroonse olekuga selle partitsiooni jaoks, v\u00f5tta liidri rolli. See on \u00e4\u00e4rmiselt vastupidav disain.<\/p>\n<p>Produtsendi konfigureerimise osa on parameeter <i>acks<\/i>, mis m\u00e4\u00e4rab, kui palju replikasid peab kinnitama s\u00f5numi vastuv\u00f5tmist, enne kui rakenduse voog j\u00e4tkab saatmist: 0, 1 v\u00f5i k\u00f5ik. Kui m\u00e4\u00e4ratakse v\u00e4\u00e4rtus <i>all<\/i>, siis kui s\u00f5num on saadud, saadab liider kinnituse tagasi produtsendile, niipea kui saab kinnitused mitmelt replikalt (sealhulgas endalt), mis on m\u00e4\u00e4ratletud teema seadistuses <i>min.insync.replicas<\/i> (`vaikimisi 1`). Kui s\u00f5numit ei \u00f5nnestu edukalt replitseerida, kutsub produtsent v\u00e4lja erandi rakendusele (<i>NotEnoughReplicas<\/i> v\u00f5i <i>NotEnoughReplicasAfterAppend<\/i>).<\/p>\n<p>T\u00fc\u00fcpilises konfiguratsioonis luuakse teema, mille replikatsioonikoefitsient on 3 (1 liider, 2 follower'it igas partitsioonis) ja parameeter <i>min.insync.replicas<\/i> seatakse v\u00e4\u00e4rtusele 2. Sel juhul lubab klaster, et \u00fcks brokeritest, kes haldab teema partitsiooni, v\u00f5iks v\u00e4lja l\u00fclituda ilma, et see m\u00f5jutaks kliendirakendusi.<\/p>\n<p>See viib meid juba tuttava kompromissi juurde, mille vahel on j\u00f5udlus ja usaldusv\u00e4\u00e4rsus. Replitseerimine toob kaasa lisakulu ooteaja kinnituste (acknowledgments) saamiseks follower'itelt. Kuigi kuna see toimub paralleelselt, on replitseerimise j\u00f5udlus v\u00e4hemalt kolmel s\u00f5lmel samasugune kui kahel (ignoreerides v\u00f5rgu lairiba kasutamise suurenemist).<\/p>\n<p>Kasutades seda replikatsiooni skeemi, v\u00e4ltib Kafka oskuslikult vajadust tagada iga s\u00f5numi f\u00fc\u00fcsiline salvestamine kettale operatsiooni kaudu <i>sync ()<\/i>. Iga s\u00f5num, mille tootja saadab, salvestatakse partitsiooni logisse, kuid nagu arutatud peat\u00fckis 2, salvestatakse fail algselt operatsiooni s\u00fcsteemi puhverisse. Kui see s\u00f5num on replitseeritud teisele Kafka instantsile ja on selle m\u00e4lus, ei t\u00e4henda juhi kadumine, et s\u00f5num ise on kadunud \u2014 selle v\u00f5ib \u00fcle v\u00f5tta s\u00fcnkroonitud replikatsioon.<br \/>\nVajaduse loobumine operatsiooni teostamiseks <i>sync ()<\/i> t\u00e4hendab, et Kafka suudab vastu v\u00f5tta s\u00f5numeid kiirusel, millega ta saab neid m\u00e4lu salvestada. Ja vastupidi, mida kauem saab v\u00e4ltida m\u00e4lu (flushing) salvestamist kettale, seda parem. Selle p\u00f5hjuseks on see, et Kafka brokeritele eraldatakse sageli 64 GB v\u00f5i rohkem m\u00e4lu. Selline m\u00e4lukasutus t\u00e4hendab, et \u00fcks Kafka instants suudab t\u00f6\u00f6tada tuhandete kordadega kiiremini kui traditsiooniline s\u00f5numite edastaja.<\/p>\n<p>Kafka saab ka seadistada rakendama operatsiooni <i>sync ()<\/i> s\u00f5numite pakettide suhtes. Kuna k\u00f5ik Kafka sisult t\u00f6\u00f6tab pakettide \u00fcmber, t\u00f6\u00f6tab see tegelikult paljude kasutusstsenaariumide jaoks \u00fcsna h\u00e4sti ja on kasulik t\u00f6\u00f6riist kasutajatele, kes n\u00f5uavad v\u00e4ga tugevaid garantiisid. Suur osa Kafka puhtast tootlikkusest on seotud s\u00f5numitega, mis saadetakse brokerile pakettidena, ja et need s\u00f5numid loetakse brokerist j\u00e4rjestikuste plokkide abil <noindex><a rel=\"nofollow\" href=\"http:\/\/www.linuxjournal.com\/article\/6345\">zero-copy<\/a><\/noindex> operatsioonide (operatsioonide, mille k\u00e4igus ei toimu andmete kopeerimist \u00fchest m\u00e4lupiirkonnast teise). Viimane on suur v\u00f5it j\u00f5udluse ja ressursside osas ning v\u00f5imalik vaid t\u00e4nu aluseks oleva logi andmestruktuuri kasutamisele, mis m\u00e4\u00e4ratleb partitsiooni skeemi.<\/p>\n<p>Kafka klastris on v\u00f5imalik saavutada tunduvalt k\u00f5rgemat j\u00f5udlust kui \u00fche Kafka brokeriga, kuna teema partitsioonid saavad horisontaalselt skaleeruda paljudele eraldi masinatele.<\/p>\n<h2>Summary<\/h2>\n<p>\nSelles peat\u00fckis k\u00e4sitleme, kuidas Kafka arhitektuur kujundab \u00fcmber kliendi ja maakleri vahelisi suhteid, et tagada uskumatult vastupidav s\u00f5numivahetuse kanal, mille l\u00e4bilaskev\u00f5ime on mitu korda suurem kui tavalise s\u00f5numiteenuse maakleri oma. Arutame funktsionaalsust, mida see eesm\u00e4rgi saavutamiseks kasutab, ja vaatleme l\u00fchidalt rakenduste arhitektuuri, mis seda funktsionaalsust toetavad. J\u00e4rgmises peat\u00fckis k\u00e4sitleme tavatarbijate s\u00f5numiteenuse rakenduste ees seisvaid \u00fcldisi probleeme ja arutame nende lahendamise strateegiaid. L\u00f5petame peat\u00fcki, k\u00e4sitledes, kuidas m\u00f5elda s\u00f5numivahetuse tehnoloogiatest \u00fcldiselt, et saaksite hinnata nende sobivust teie kasutusstsenaariumidesse.<\/p>\n<p>Eelmine t\u00f5lgitud osa: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">S\u00f5numivahendite m\u00f5istmine. Teadevahetuse mehhaanika uurimine ActiveMQ ja Kafka abil. Peat\u00fckk 1<\/a><\/noindex><\/p>\n<p><b> Translation completed: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p><i>J\u00e4tkub&#8230;<\/i><\/p>\n<p class=\"for_users_only_msg\">Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Logige sisse<\/a><\/noindex>, palun.<\/p>\n<h2 class=\"default-block__polling-title\">Kasutatakse kas Kafka teie organisatsioonis?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Jah<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ei<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Varem kasutati, praegu ei kasutata<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Plaanis kasutada<\/p>\n<\/li>\n<\/ul>\n<p>    38 kasutajat h\u00e4\u00e4letasid. 8 kasutajat hoidusid.<br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466585\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#8217;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c: \u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0413\u041b\u0410\u0412\u0410 3 Kafka Kafka \u0431\u044b\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u0430 \u0432 LinkedIn \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0431\u043e\u0439\u0442\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38172","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#039;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 3. Kafka | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#039;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:22:05+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:22:05+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47S\u00f5numiteenuste m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka | ProHoster","description":"J\u00e4tkub v\u00e4ikese raamatu t\u00f5lge: 'Understanding Message Brokers', autor: Jakub Korab, kirjastus: O'Reilly Media, Inc., v\u00e4ljaandmise kuup\u00e4ev: juuni 2017, ISBN: 9781492049296. Eelmine t\u00f5lge.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 3. Kafka | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O'Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:22:05+00:00","article:modified_time":"2019-10-31T19:22:05+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38172","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 20:46:00","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:34:26","updated":"2026-01-23 20:46:00","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/38172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=38172"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/38172\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=38172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=38172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=38172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}