{"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\/sl\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","title":{"rendered":"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Nadaljevanje prevoda majhne knjige:<br \/>\n\u00abRazumevanje sporo\u010dilnih posrednikov\u00bb<br \/>\navtor: Jakub Korab, zalo\u017enik: O'Reilly Media, Inc., datum izdaje: jun 2017, ISBN: 9781492049296.<\/p>\n<p>Prej\u0161nji prevedeni del: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">Razumevanje sporo\u010dilnih posrednikov. \u0160tudij mehanike izmenjave sporo\u010dil preko ActiveMQ in Kafka. Poglavje 1. Uvod<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>POGLAVJE 3<\/h2>\n<p><\/p>\n<h2>Kafka<\/h2>\n<p>\nKafka je bila zasnovana v LinkedInu, da bi ob\u0161la nekatere omejitve tradicionalnih sporo\u010dilnih posrednikov in se izognila potrebi po konfiguraciji ve\u010d sporo\u010dilnih posrednikov za razli\u010dne interakcije 'to\u010dka-to\u010dka', kar je opisano v tej knjigi v razdelku 'Vertikalno in horizontalno skaliranje' na strani 28. Uporabni\u0161ki scenariji v LinkedInu so se ve\u010dinoma osredoto\u010dali na enosmerno absorpcijo zelo velikih koli\u010din podatkov, kot so kliki na straneh in dnevniki dostopa, pri \u010demer so omogo\u010dili uporabo teh podatkov ve\u010d sistemom, ne da bi vplivali na zmogljivost producentov ali drugih potro\u0161nikov. Dejansko je razlog za obstoj Kafke, da zagotavlja tako arhitekturo izmenjave sporo\u010dil, kot jo opisuje Univerzalna podatkovna cev.<\/p>\n<p>Ob upo\u0161tevanju te kon\u010dne cilje so se naravno pojavile tudi druge zahteve. Kafka mora:<\/p>\n<ul>\n<li>Biti izjemno hitra<\/li>\n<li>Zagotavljati visoko prepustnost pri obdelavi sporo\u010dil<\/li>\n<li>Podpirati modele 'Zalo\u017enik-Naro\u010dnik' in 'To\u010dka-To\u010dka'<\/li>\n<li>Ne upo\u010dasniti se z dodajanjem potro\u0161nikov. Na primer, zmogljivost tako vrstic kot tudi topicov v ActiveMQ se poslab\u0161a z nara\u0161\u010danjem \u0161tevila potro\u0161nikov na naslovniku<\/li>\n<li>Biti horizontalno skalabilna; \u010de lahko en broker, ki shranjuje sporo\u010dila, to po\u010dne le z najve\u010djo hitrostjo diska, ima smisel, da prese\u017eemo en sam primer brokerja, da pove\u010damo zmogljivost<\/li>\n<li>Razmejiti dostop do shranjevanja in ponovnega pridobivanja sporo\u010dil<\/li>\n<\/ul>\n<p>\nDa bi dosegli vse to, je v Kafki sprejeta arhitektura, ki je spremenila vloge in odgovornosti odjemalcev in posrednikov za izmenjavo sporo\u010dil. Model JMS je zelo usmerjen v posrednika, ki je odgovoren za \u0161irjenje sporo\u010dil, medtem ko se morajo odjemalci osredoto\u010diti le na po\u0161iljanje in prejemanje sporo\u010dil. Kafka pa je usmerjena k odjemalcu, pri \u010demer odjemalec prevzema \u0161tevilne funkcije tradicionalnega posrednika, kot je pravi\u010dna porazdelitev ustreznih sporo\u010dil med potro\u0161niki, v zameno pa pridobiva izjemno hitro in raz\u0161irljivo storitev posredovanja. Za ljudi, ki so delali s tradicionalnimi sistemi za izmenjavo sporo\u010dil, delo s Kafko zahteva temeljne spremembe v pogledu.<br \/>\nTa in\u017eenirski pristop je privedel do nastanka infrastrukture za izmenjavo sporo\u010dil, sposobne pove\u010dati prepustnost za ve\u010d vrst po vrstah v primerjavi s tradicionalnim posrednikom. Kot bomo videli, je ta pristop povezan s kompromisi, ki pomenijo, da Kafka ni primerna za dolo\u010dene vrste obremenitev in obstoje\u010dih programske opreme.<\/p>\n<h3>Enotna model naslovnika<\/h3>\n<p>\nDa bi izpolnili zgoraj opisane zahteve, je Kafka zdru\u017eila izmenjavo sporo\u010dil tipa \"objava-naro\u010danje\" in \"to\u010dka-to\u010dka\" v okviru ene vrste naslovnika \u2014 <i>teme<\/i>. To zmede ljudi, ki so delali s sistemi izmenjave sporo\u010dil, kjer beseda \"tema\" pomeni \u0161irokomehanizem, iz katerega branje (iz teme) ni zanesljivo (je nezanesljivo). Temam Kafke je treba gledati kot na hibridno vrsto naslovnika, v skladu s definicijo, dano v uvodu te knjige.<\/p>\n<blockquote><p>V preostalem delu te poglavja, razen \u010de izrecno navedemo druga\u010de, bo izraz \"tema\" nana\u0161al na temo Kafke.<\/p><\/blockquote>\n<p>\nDa bi popolnoma razumeli, kako se teme obna\u0161ajo in katere garancije ponujajo, moramo najprej obravnavati, kako so implementirane v Kafki.<br \/>\n<i>Vsaka tema v Kafki ima svoj dnevnik.<\/i><br \/>\nProducenci, kt\u00f3rzy wysy\u0142aj\u0105 komunikaty do Kafki, zapisuj\u0105 je w tym dzienniku, a konsumenci odczytuj\u0105 z dziennika za pomoc\u0105 wska\u017anik\u00f3w, kt\u00f3re nieustannie przesuwaj\u0105 si\u0119 do przodu. Okresowo Kafka usuwa najstarsze cz\u0119\u015bci dziennika, niezale\u017cnie od tego, czy komunikaty w tych cz\u0119\u015bciach zosta\u0142y odczytane, czy nie. Centralnym elementem projektu Kafki jest to, \u017ce broker nie przejmuje si\u0119 tym, czy komunikaty zosta\u0142y odczytane, czy nie \u2014 to jest odpowiedzialno\u015b\u0107 klienta.<\/p>\n<blockquote><p>Terminy \u201edziennik\u201d i \u201ewska\u017anik\u201d nie wyst\u0119puj\u0105 w <noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation.html\">dokumentacji Kafki<\/a><\/noindex>. Te dobrze znane terminy s\u0105 u\u017cywane tutaj, aby u\u0142atwi\u0107 zrozumienie.<\/p><\/blockquote>\n<p>\nTen model r\u00f3\u017cni si\u0119 ca\u0142kowicie od ActiveMQ, gdzie komunikaty z wszystkich kolejek s\u0105 przechowywane w jednym dzienniku, a broker oznacza komunikaty jako usuni\u0119te po ich odczytaniu.<br \/>\nPrzyjrzyjmy si\u0119 teraz nieco bli\u017cej dziennikowi tematu.<br \/>\nDziennik Kafki sk\u0142ada si\u0119 z kilku partycji (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/tm\/w2\/yf\/tmw2yf3lanppqtrumxoidotplhi.png\">Rysunek 3-1<\/a><\/noindex>). Kafka gwarantuje \u015bcis\u0142\u0105 kolejno\u015b\u0107 w ka\u017cdej partycji. Oznacza to, \u017ce komunikaty zapisane w partycji w okre\u015blonym porz\u0105dku b\u0119d\u0105 odczytywane w tym samym porz\u0105dku. Ka\u017cda partycja zrealizowana jest w postaci cyklicznego pliku dziennika, kt\u00f3ry zawiera <i>podzbi\u00f3r <\/i>(subset) wszystkich komunikat\u00f3w wys\u0142anych do tematu przez jego producent\u00f3w. Utworzony temat domy\u015blnie zawiera jedn\u0105 partycj\u0119. Pomys\u0142 partycji jest centralnym pomys\u0142em Kafki na poziome skalowanie.<\/p>\n<p><img decoding=\"async\" alt=\"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/39f41ebcb73ec247656c0dea438158a9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Rysunek 3-1. Partycje Kafki<\/i><\/p>\n<p>Gdy producent wysy\u0142a komunikat do tematu Kafki, decyduje, do kt\u00f3rej partycji wys\u0142a\u0107 komunikat. Przyjrzymy si\u0119 temu bardziej szczeg\u00f3\u0142owo p\u00f3\u017aniej.<\/p>\n<h2>\u010citanje poruka<\/h2>\n<p>\nKlient, kt\u00f3ry chce odczyta\u0107 komunikaty, zarz\u0105dza nazwanym wska\u017anikiem, zwanym <i>grup\u0105 konsument\u00f3w (consumer group)<\/i>, kt\u00f3ry wskazuje na <i>offset<\/i> komunikatu w partycji. Offset to pozycja z rosn\u0105cym numerem, kt\u00f3ra zaczyna si\u0119 od 0 na pocz\u0105tku partycji. Ta grupa konsument\u00f3w, na kt\u00f3r\u0105 wskazuje si\u0119 w API przez definiowany przez u\u017cytkownika identyfikator group_id, odpowiada <i>jednemu logicznemu konsumentowi lub systemowi.<\/i>.<\/p>\n<p>Wi\u0119kszo\u015b\u0107 system\u00f3w korzystaj\u0105cych z wymiany komunikat\u00f3w odczytuje dane z adresata za pomoc\u0105 kilku instancji i w\u0105tk\u00f3w w celu r\u00f3wnoleg\u0142ego przetwarzania komunikat\u00f3w. Dlatego zazwyczaj b\u0119dzie wiele instancji konsument\u00f3w wsp\u00f3\u0142dziel\u0105cych t\u0119 sam\u0105 grup\u0119 konsument\u00f3w.<\/p>\n<p>Te\u017eavo branja lahko predstavimo na naslednji na\u010din:<\/p>\n<ul>\n<li>Tematika ima ve\u010d particij.<\/li>\n<li>Tematika lahko hkrati uporablja ve\u010d skupin porabnikov.<\/li>\n<li>Skupina porabnikov lahko ima ve\u010d lo\u010denih instanc.<\/li>\n<\/ul>\n<p>\nTo je netrivialen problem \"mnoge proti mnogim\". Da bi razumeli, kako Kafka obravnava odnose med skupinami porabnikov, instancami porabnikov in particijami, si poglejmo vrsto postopoma zahtevnej\u0161ih scenarijev branja.<\/p>\n<h3>Porabniki in skupine porabnikov<\/h3>\n<p>\nVzemimo za izhodi\u0161\u010de tematiko z eno particijo (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/6z\/tz\/dh\/6ztzdhqmjweck-z15htxb2xbe28.png\">Slika 3-2<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/46c92e6bd38774dfef3be4bd198bf35d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 3-2. Porabnik bere iz particije<\/i><\/p>\n<p>Ko se instanca porabnika pove\u017ee s svojim lastnim group_id na to tematiko, ji je dodeljena particija za branje in offset v tej particiji. Polo\u017eaj tega offseta je konfiguriran v odjemalcu kot kazalec na najnovej\u0161o pozicijo (najnovej\u0161a sporo\u010dila) ali najstarej\u0161o pozicijo (najstarej\u0161a sporo\u010dila). Porabnik zahteva (polls) sporo\u010dila iz tematike, kar privede do njihovega zaporednega branja iz dnevnika.<br \/>\nPolo\u017eaj offseta se redno potrjuje nazaj v Kafka in se shrani kot sporo\u010dila v notranji tematiki <i>_consumer_offsets<\/i>. Prebrana sporo\u010dila se vseeno ne izbri\u0161ejo, za razliko od obi\u010dajnega posrednika, in stranka lahko previje (rewind) offset, da ponovno obdeluje \u017ee pregledana sporo\u010dila.<\/p>\n<p>Ko se pove\u017ee drugi logi\u010dni porabnik, ki uporablja drug group_id, upravlja z drugim kazalcem, ki ni odvisen od prvega (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/qe\/v1\/yk\/qev1yktga3s-g1gqlynylbe3n9w.png\">Slika 3-3<\/a><\/noindex>). Tako tematika Kafka deluje kot vrsta, v kateri obstaja en porabnik, in kot obi\u010dajna tematika zalo\u017enik-naro\u010dnik (pub-sub), na katero se naro\u010di ve\u010d porabnikov, s dodatno prednostjo, da se vsa sporo\u010dila shranijo in jih je mogo\u010de obdelovati ve\u010dkrat.<\/p>\n<p><img decoding=\"async\" alt=\"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/e9e8b9063ef7367005254d36abb47f4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 3-3. Dva porabnika v razli\u010dnih skupinah porabnikov bereta iz ene particije<\/i><\/p>\n<h3>Porabniki v skupini porabnikov<\/h3>\n<p>\nKo ena instanca porabnika bere podatke iz particije, popolnoma nadzira kazalec in obdeluje sporo\u010dila, kot je opisano v prej\u0161njem razdelku.<br \/>\n\u010ce so bili ve\u010d primerkov potro\u0161nikov povezani z istim group_id s temo z eno particijo, bo zadnjemu povezanemu primeru dodeljena kontrola nad kazalnikom, in od tega trenutka naprej bo prejemal vse sporo\u010dila (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/0j\/ao\/f2\/0jaof2mdwg3cqvmwemhtxkrltuq.png\">Slika 3-4<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/ec6af819445dad4028f65449a735ae22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Slika 3-4. Dva potro\u0161nika v isti skupini potro\u0161nikov bereta iz ene particije<\/i><\/p>\n<p>Ta na\u010din obdelave, v katerem \u0161tevilo primerkov potro\u0161nikov presega \u0161tevilo particij, se lahko obravnava kot vrsta monopolnega potro\u0161nika. To je lahko koristno, \u010de potrebujete 'aktivno-pasivno' (ali 'vro\u010do-toplo') klasterizacijo va\u0161ih primerkov potro\u0161nikov, \u010deprav je hkratno delovanje ve\u010d potro\u0161nikov ('aktivno-aktivno' ali 'vro\u010de-vro\u010de') precej bolj obi\u010dajno kot potro\u0161niki v na\u010dinu \u010dakanja.<\/p>\n<blockquote><p>Tak\u0161no vedenje porazdelitve sporo\u010dil, opisano zgoraj, lahko preseneti v primerjavi s tem, kako se obna\u0161a obi\u010dajen JMS \u010dakalni red. V tem modelu se sporo\u010dila, poslana v \u010dakalni red, enakomerno razporedijo med dvema potro\u0161nikoma.<\/p><\/blockquote>\n<p>\nNajpogosteje, ko ustvarimo ve\u010d primerkov potro\u0161nikov, to po\u010dnemo bodisi za paralelno obdelavo sporo\u010dil, bodisi za pove\u010danje hitrosti branja, bodisi za pove\u010danje odpornosti postopka branja. Ker lahko podatke iz particije hkrati bere le en primer potro\u0161nika, kako to dose\u017eejo v Kafki?<\/p>\n<p>Eden od na\u010dinov za to je uporaba enega primerka potro\u0161nika, da prebere vsa sporo\u010dila in jih prenese v skupino niti. \u010ceprav ta pristop pove\u010duje prepustnost obdelave, pove\u010duje te\u017eavnost logike potro\u0161nikov in ne pove\u010duje odpornosti bralnega sistema. \u010ce se en primer potro\u0161nika izklju\u010di zaradi izpada elektri\u010dne energije ali podobnega dogodka, prebiranje preneha.<\/p>\n<p>Kanoni\u010den na\u010din re\u0161evanja tega problema v Kafki je uporaba ve\u010d<i>O<\/i>particij.<\/p>\n<h3>Particioniranje<\/h3>\n<p>\nParticije so glavni mehanizem za razpr\u0161evanje branja in skaliranje teme onkraj prepustnosti enega brokera. Da bi bolje razumeli to, si poglejmo situacijo, kjer obstaja tema z dvema particijama in na to temo se prijavi en potro\u0161nik (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/en\/9g\/ct\/en9gct0o017cqp8buawguwlscty.png\">Slika 3-5<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/cc766bf69af22698aacc3f1ac70b067f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>\u0420\u0438\u0441\u0443\u043d\u043e\u043a 3-5. \u041e\u0434\u0438\u043d \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440 \u0447\u0438\u0442\u0430\u0435\u0442 \u0438\u0437 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0439<\/i><\/p>\n<p>\u0412 \u044d\u0442\u043e\u043c \u0441\u0446\u0435\u043d\u0430\u0440\u0438\u0438 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c \u043d\u0430\u0434 \u0443\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044f\u043c\u0438, \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u043c\u0438 \u0435\u0433\u043e group_id \u0432 \u043e\u0431\u0435\u0438\u0445 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u044f\u0445, \u0438 \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u0442 \u0447\u0442\u0435\u043d\u0438\u0435 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438\u0437 \u043e\u0431\u0435\u0438\u0445 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0439.<br \/>\n\u041a\u043e\u0433\u0434\u0430 \u0432 \u044d\u0442\u043e\u0442 \u0442\u043e\u043f\u0438\u043a \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0434\u043e\u043f\u043e\u043b\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440 \u0434\u043b\u044f \u0442\u043e\u0433\u043e \u0436\u0435 group_id, Kafka \u043f\u0435\u0440\u0435\u043d\u0430\u0437\u043d\u0430\u0447\u0430\u0435\u0442 (reallocate) \u043e\u0434\u043d\u0443 \u0438\u0437 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0439 \u0441 \u043f\u0435\u0440\u0432\u043e\u0433\u043e \u043d\u0430 \u0432\u0442\u043e\u0440\u043e\u0439 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440. \u041f\u043e\u0441\u043b\u0435 \u0447\u0435\u0433\u043e \u043a\u0430\u0436\u0434\u044b\u0439 \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u0430 \u0431\u0443\u0434\u0435\u0442 \u0447\u0438\u0442\u0430\u0442\u044c\u0441\u044f \u0438\u0437 \u043e\u0434\u043d\u043e\u0439 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0438 \u0442\u043e\u043f\u0438\u043a\u0430 (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/8b\/a0\/um\/8ba0umn2yzr9yy3vztonhdfiub0.png\">\u0420\u0438\u0441\u0443\u043d\u043e\u043a 3-6<\/a><\/noindex>).<\/p>\n<p>\u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0443 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u044c\u043d\u043e \u0432 20 \u043f\u043e\u0442\u043e\u043a\u043e\u0432, \u0432\u0430\u043c \u043f\u043e\u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u043a\u0430\u043a \u043c\u0438\u043d\u0438\u043c\u0443\u043c 20 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0439. \u0415\u0441\u043b\u0438 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0439 \u0431\u0443\u0434\u0435\u0442 \u043c\u0435\u043d\u044c\u0448\u0435, \u0443 \u0432\u0430\u0441 \u043e\u0441\u0442\u0430\u043d\u0443\u0442\u0441\u044f \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u043d\u0435 \u043d\u0430\u0434 \u0447\u0435\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c, \u0447\u0442\u043e \u0443\u0436\u0435 \u043e\u0431\u0441\u0443\u0436\u0434\u0430\u043b\u043e\u0441\u044c \u0440\u0430\u043d\u0435\u0435 \u0432 \u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u0435 \u043c\u043e\u043d\u043e\u043f\u043e\u043b\u044c\u043d\u044b\u0445 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u043e\u0432.<\/p>\n<p><img decoding=\"async\" alt=\"Razumevanje brokera poruka. Istra\u017eivanje mehanike razmene poruka putem ActiveMQ i Kafka. Poglavlje 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/a3c4001e4a5b92d53b6f529b2633254a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>\u0420\u0438\u0441\u0443\u043d\u043e\u043a 3-6. \u0414\u0432\u0430 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u0430 \u0432 \u043e\u0434\u043d\u043e\u0439 \u0438 \u0442\u043e\u0439 \u0436\u0435 \u0433\u0440\u0443\u043f\u043f\u0435 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u043e\u0432 \u0447\u0438\u0442\u0430\u044e\u0442 \u0438\u0437 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u0439<\/i><\/p>\n<p>\u042d\u0442\u0430 \u0441\u0445\u0435\u043c\u0430 \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u0431\u0440\u043e\u043a\u0435\u0440\u0430 Kafka \u043f\u043e \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u044e \u0441 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u0435\u043c \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439, \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b\u043c \u0434\u043b\u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u043e\u0447\u0435\u0440\u0435\u0434\u0438 JMS. \u0417\u0434\u0435\u0441\u044c \u043d\u0435 \u043d\u0443\u0436\u043d\u043e \u0437\u0430\u0431\u043e\u0442\u0438\u0442\u044c\u0441\u044f \u043e \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0445 \u043c\u043e\u043c\u0435\u043d\u0442\u0430\u0445:<\/p>\n<ul>\n<li>\u041a\u0430\u043a\u043e\u0439 \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440 \u0434\u043e\u043b\u0436\u0435\u043d \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0435 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435, \u043e\u0441\u043d\u043e\u0432\u044b\u0432\u0430\u044f\u0441\u044c \u043d\u0430 \u0446\u0438\u043a\u043b\u0438\u0447\u0435\u0441\u043a\u043e\u043c (round-robin) \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u0438, \u0442\u0435\u043a\u0443\u0449\u0435\u0439 \u0435\u043c\u043a\u043e\u0441\u0442\u0438 \u0431\u0443\u0444\u0435\u0440\u043e\u0432 \u043f\u0440\u0435\u0434\u0432\u0430\u0440\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0439 \u0432\u044b\u0431\u043e\u0440\u043a\u0438 \u0438\u043b\u0438 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u0445 (\u043a\u0430\u043a \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0433\u0440\u0443\u043f\u043f \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 JMS).<\/li>\n<li>\u041a\u0430\u043a\u0438\u0435 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u044b \u043a\u0430\u043a\u0438\u043c \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u0430\u043c \u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u043b\u0438 \u043e\u043d\u0438 \u0431\u044b\u0442\u044c \u0434\u043e\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u044b \u043f\u043e\u0432\u0442\u043e\u0440\u043d\u043e \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441\u0431\u043e\u044f.<\/li>\n<\/ul>\n<p>\n\u0412\u0441\u0435, \u0447\u0442\u043e \u0434\u043e\u043b\u0436\u0435\u043d \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0431\u0440\u043e\u043a\u0435\u0440 Kafka \u2014 \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u043f\u0435\u0440\u0435\u0434\u0430\u0432\u0430\u0442\u044c \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043a\u043e\u043d\u0441\u044e\u043c\u0435\u0440\u0443, \u043a\u043e\u0433\u0434\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0439 \u0437\u0430\u043f\u0440\u0430\u0448\u0438\u0432\u0430\u0435\u0442 \u0438\u0445.<\/p>\n<p>\u041e\u0434\u043d\u0430\u043a\u043e, \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u043a \u0440\u0430\u0441\u043f\u0430\u0440\u0430\u043b\u043b\u0435\u043b\u0438\u0432\u0430\u043d\u0438\u044e \u0432\u044b\u0447\u0438\u0442\u043a\u0438 \u0438 \u043f\u043e\u0432\u0442\u043e\u0440\u043d\u043e\u0439 \u043e\u0442\u043f\u0440\u0430\u0432\u043a\u0435 \u043d\u0435\u0443\u0434\u0430\u0447\u043d\u044b\u0445 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u043d\u0438\u043a\u0443\u0434\u0430 \u043d\u0435 \u0434\u0435\u0432\u0430\u044e\u0442\u0441\u044f \u2014 \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0437\u0430 \u043d\u0438\u0445 \u043f\u0440\u043e\u0441\u0442\u043e \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0438\u0442 \u043e\u0442 \u0431\u0440\u043e\u043a\u0435\u0440\u0430 \u043a \u043a\u043b\u0438\u0435\u043d\u0442\u0443. \u042d\u0442\u043e \u043e\u0437\u043d\u0430\u0447\u0430\u0435\u0442, \u0447\u0442\u043e \u043e\u043d\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0431\u044b\u0442\u044c \u0443\u0447\u0442\u0435\u043d\u044b \u0432 \u0432\u0430\u0448\u0435\u043c \u043a\u043e\u0434\u0435.<\/p>\n<h2>\u041e\u0442\u043f\u0440\u0430\u0432\u043a\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439<\/h2>\n<p>\n\u041e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0437\u0430 \u0442\u043e, \u0432 \u043a\u0430\u043a\u0443\u044e \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u044e \u043e\u0442\u043f\u0440\u0430\u0432\u0438\u0442\u044c \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435, \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u0435\u0442\u0441\u044f \u043d\u0430 \u043f\u0440\u043e\u0434\u044e\u0441\u0435\u0440\u0430 \u044d\u0442\u043e\u0433\u043e \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f. \u0427\u0442\u043e\u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c, \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u044d\u0442\u043e \u0434\u0435\u043b\u0430\u0435\u0442\u0441\u044f, \u0441\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0443\u0436\u043d\u043e \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c, \u0447\u0442\u043e \u0438\u043c\u0435\u043d\u043d\u043e \u043c\u044b \u043d\u0430 \u0441\u0430\u043c\u043e\u043c \u0434\u0435\u043b\u0435 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u043c.<\/p>\n<p>\u0412 \u0442\u043e \u0432\u0440\u0435\u043c\u044f \u043a\u0430\u043a \u0432 JMS \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u0441 \u043c\u0435\u0442\u0430\u0434\u0430\u043d\u043d\u044b\u043c\u0438 (\u0437\u0430\u0433\u043e\u043b\u043e\u0432\u043a\u0430\u043c\u0438 \u0438 \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c\u0438) \u0438 \u0442\u0435\u043b\u043e\u043c, \u0441\u043e\u0434\u0435\u0440\u0436\u0430\u0449\u0438\u043c \u043f\u043e\u043b\u0435\u0437\u043d\u0443\u044e \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 (payload), \u0432 Kafka \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f <i>\u043f\u0430\u0440\u043e\u0439 \u00ab\u043a\u043b\u044e\u0447-\u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435\u00bb<\/i>Navozna obvestila se po\u0161ilja kot vrednost (value). Klju\u010d pa se uporablja predvsem za partitioning in mora vsebovati <i>klju\u010d specifi\u010den za poslovno logiko<\/i>, da se povezana obvestila postavijo v isto particijo.<\/p>\n<p>V Poglavju 2 smo obravnavali scenarij spletnih stav, kjer morajo biti povezana dogodka obdelana zaporedno z enim porabnikom:<\/p>\n<ol>\n<li>Uporabni\u0161ki ra\u010dun je nastavljen.<\/li>\n<li>Denar je nakazan na ra\u010dun.<\/li>\n<li>Uveljavljen je stavek, ki dvigne denar z ra\u010duna.<\/li>\n<\/ol>\n<p>\n\u010ce vsak dogodek predstavlja sporo\u010dilo, poslano v temo, potem bo v tem primeru naravni klju\u010d identifikator ra\u010duna.<br \/>\nKo se sporo\u010dilo po\u0161lje z uporabo Kafka Producer API, se prenese na funkcijo partitioniranja, ki, upo\u0161tevajo\u010d sporo\u010dilo in trenutno stanje Kafka klasterja, vrne identifikator particije, v katero mora biti sporo\u010dilo poslano. Ta funkcija je implementirana v Javi preko vmesnika Partitioner.<\/p>\n<p>Ta vmesnik izgleda takole:<\/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>\nImplementacija Partitioner za dolo\u010ditev particije uporablja privzeto algoritme hashiranja klju\u010da (general-purpose hashing algorithm over the key) ali kro\u017eno premo\u0161\u010danje (round-robin), \u010de klju\u010d ni naveden. Ta privzeta vrednost deluje dobro v ve\u010dini primerov. Vendar pa boste morda \u017eeleli v prihodnosti napisati svojo.<\/p>\n<h3>Pisanje lastne strategije partitioniranja<\/h3>\n<p>\nPoglejmo primer, kjer \u017eelite poslati metapodatke skupaj s koristno obremenitvijo sporo\u010dila. Koristna obremenitev v na\u0161em primeru je navodilo za polog na igralni ra\u010dun. Navodilo je tisto, kar bi \u017eeleli zagotovo ne spremeniti med prenosom in \u017eelimo biti prepri\u010dani, da lahko to navodilo spro\u017ei le zaupanja vredni vi\u0161ji sistem. V tem primeru se po\u0161iljateljske in sprejemne sisteme dogovorijo o uporabi podpisa za preverjanje pristnosti sporo\u010dila.<br \/>\nV obi\u010dajnem JMS preprosto definiramo lastnost \"podpis sporo\u010dila\" in jo dodamo sporo\u010dilu. Vendar pa Kafka ne nudi mehanizma za prenos metapodatkov \u2014 le klju\u010d in vrednost.<\/p>\n<p>Ker ker je vrednost \u2014 to prozra\u010dna obdelava ban\u010dnega prenosa (bank transfer payload), katere celovitost \u017eelimo ohraniti, nimamo druge izbire, kot da dolo\u010dimo strukturo podatkov, ki jo bomo uporabili v klju\u010du. Predpostavljamo, da potrebujemo identifikator ra\u010duna za particioniranje, saj morajo biti vse povezana sporo\u010dila povezana z ra\u010dunom obdelana v vrstnem redu, zato bomo zasnovali naslednjo JSON strukturo:<\/p>\n<pre><code class=\"json\">{\n  \"signature\": \"541661622185851c248b41bf0cea7ad0\",\n  \"accountId\": \"10007865234\"\n}<\/code><\/pre>\n<p>\nKer se bo vrednost podpisa spreminjala glede na obdelavo, privzeta strategija hashiranja vmesnika Partitioner ne bo zanesljivo zdru\u017eevala povezanih sporo\u010dil. Zato bomo morali napisati svojo strategijo, ki bo analizirala ta klju\u010d in razdelila (partition) vrednost accountId.<\/p>\n<blockquote><p>Kafka vklju\u010duje kontrolne vsote za odkrivanje po\u0161kodb sporo\u010dil v shranjevanju in ima popoln nabor funkcij varnosti. Kljub temu se v\u010dasih pojavijo specifi\u010dne zahteve za industrijo, kot je zgoraj navedeno.<\/p><\/blockquote>\n<p>\nUporabni\u0161ka strategija particioniranja mora zagotavljati, da se vsa povezana sporo\u010dila znajdejo v eni particiji. \u010ceprav se to zdi enostavno, se lahko zahteva zaplete zaradi pomembnosti ohranjanja zaporedja povezanih sporo\u010dil in koli\u010dine particij v temi, ki mora biti fiksna.<\/p>\n<p>\u0160tevilo particij v temi se lahko s\u010dasoma spreminja, saj jih je mogo\u010de dodati, \u010de promet prese\u017ee prvotna pri\u010dakovanja. Tako so lahko klju\u010di sporo\u010dil povezani s particijo, v katero so bila prvotno poslana, kar implicira del stanja, ki ga je treba razporediti med primerki proizvajalca.<\/p>\n<p>Drug dejavnik, ki ga je treba upo\u0161tevati, je enakomernost porazdelitve sporo\u010dil med particijami. Na splo\u0161no se klju\u010di ne porazdelijo enakomerno med sporo\u010dili, in hash funkcije ne zagotavljajo pravi\u010dne porazdelitve sporo\u010dil za majhen nabor klju\u010dev.<br \/>\nPomembno je omeniti, da, ne glede na to, kako se odlo\u010dite razdeliti sporo\u010dila, bo morda treba razdelilnik ponovno uporabiti.<\/p>\n<p>Razmotrimo zahtevanje replikacije podataka izme\u0111u Kafka klastera na razli\u010ditim geografskim lokacijama. U te svrhe, Kafka dolazi sa alatkom komandne linije pod nazivom MirrorMaker, koja se koristi za \u010ditanje poruka iz jednog klastera i njihov prenos u drugi.<\/p>\n<p>MirrorMaker mora razumeti klju\u010deve replikovanog topika kako bi odr\u017eavao relativnu pravila izme\u0111u poruka prilikom replikacije izme\u0111u klastera, po\u0161to broj particija za ovaj topik mo\u017ee da se ne poklapa u dva klastera.<\/p>\n<p>Korisni\u010dke strategije particionisanja se relativno retko sre\u0107u, jer defaultne he\u0161iranje ili cikli\u010dki iteriraju\u0107i pristup uspe\u0161no funkcioni\u0161u u ve\u0107ini scenarija. Me\u0111utim, ako su vam potrebna stroga obezbe\u0111enja redosleda ili trebate izvu\u0107i metapodatke iz optere\u0107enja, particionisanje je ne\u0161to \u010demu biste trebali posvetiti vi\u0161e pa\u017enje.<\/p>\n<p>Prednosti skalabilnosti i performansi Kafke su rezultat premestanja nekih obaveza tradicionalnog brokera na klijenta. U ovom slu\u010daju, donosi se odluka o raspodeli potencijalno povezanih poruka me\u0111u vi\u0161e potro\u0161a\u010da koji rade paralelno.<\/p>\n<blockquote><p>JMS brokeri se tako\u0111e moraju nositi sa sli\u010dnim zahtevanjima. Zanimljivo je da mehanizam slanja povezanih poruka istom potro\u0161a\u010du, implementiran kroz JMS Message Groups (vrsta strategije balansiranja opcija sticky load balancing (SLB)), tako\u0111e zahteva da po\u0161iljalac ozna\u010di poruke kao povezane. U slu\u010daju JMS, broker je odgovoran za slanje ove grupe povezanih poruka jednom potro\u0161a\u010du od mnogih i prenos prava vlasni\u0161tva nad grupom ukoliko potro\u0161a\u010d otpadne.<\/p><\/blockquote>\n<p><\/p>\n<h2>Dogovori o producentu<\/h2>\n<p>\nParticionisanje nije jedino \u0161to treba razmotriti prilikom slanja poruka. Pogledajmo metode send() klase Producer u Java API:<\/p>\n<pre><code class=\"java\">Future  send(ProducerRecord  record);\nFuture  send(ProducerRecord  record, Callback callback);<\/code><\/pre>\n<p>\nTakoj je pomembno omeniti, da oba metoda vra\u010data Future, kar pomeni, da operacija po\u0161iljanja ni izvedena takoj. Rezultat je, da se sporo\u010dilo (ProducerRecord) zapi\u0161e v po\u0161iljateljski pomnilnik za vsako aktivno particijo in se prenese brokerju v ozadju v knji\u017enici odjemalca Kafka. \u010ceprav to delo neverjetno pospe\u0161i, to pomeni, da slabo zasnovana aplikacija lahko izgubi sporo\u010dila, \u010de se njen proces ustavi.<\/p>\n<p>Kot vedno je na\u010din, da po\u0161iljanje naredimo bolj zanesljivo, na ra\u010dun zmogljivosti. Velikost te pomnilni\u0161ke konstrukcije lahko nastavite na 0, kar bo prisililo tok po\u0161iljajo\u010de aplikacije, da \u010daka, dokler prenosa sporo\u010dila brokerju ne bo kon\u010dana, in sicer takole:<\/p>\n<pre><code class=\"java\">RecordMetadata metadata = producer.send(record).get();<\/code><\/pre>\n<p><\/p>\n<h2>\u0160e enkrat o branju sporo\u010dil<\/h2>\n<p>\nBranje sporo\u010dil ima dodatne zapletenosti, o katerih je treba razmisliti. V nasprotju z API JMS, ki lahko za\u017eene poslu\u0161alca sporo\u010dil (message listener) kot odgovor na prejem sporo\u010dila, vmesnik <i>Consumer <\/i>Kafka le vpra\u0161a (polling). Poglejmo podrobneje metodo <i>poll ()<\/i>, uporabljeno za ta namen:<\/p>\n<pre><code class=\"java\">ConsumerRecords  poll(long timeout);<\/code><\/pre>\n<p>\nVrnjena vrednost metode je struktura, ki vsebuje ve\u010d objektov <i>ConsumerRecord <\/i>iz potencialno ve\u010d particij. <i>ConsumerRecord <\/i>sama je objekt, ki hrani par klju\u010d-vrednost skupaj z ustreznimi metapodatki, kot je particija, iz katere je pridobljena.<\/p>\n<p>Kot je bilo razlo\u017eeno v poglavju 2, se moramo nenehno spominjati, kaj se zgodi s sporo\u010dili po uspe\u0161ni ali neuspe\u0161ni obdelavi, na primer, \u010de stranka ne more obdelati sporo\u010dila ali \u010de pride do prekinitve delovanja. V JMS je bilo to obravnavano preko na\u010dina potrjevanja (acknowledgement mode). Broker bodisi izbri\u0161e uspe\u0161no obdelano sporo\u010dilo bodisi ponovno dostavi neobdelano ali neuspelo (ob predpostavki, da so bile uporabljene transakcije). <br \/>\nKafka deluje povsem druga\u010de. Sporo\u010dila se ne izbri\u0161ejo na brokerju po branju in odgovornost za to, kar se zgodi ob napaki, le\u017ei na samem bralnem kodu.<\/p>\n<p>Kot smo \u017ee omenili, je skupina potro\u0161nikov povezana z odklonom v dnevniku. Polo\u017eaj v dnevniku, povezan s tem odklonom, ustreza naslednjemu sporo\u010dilu, ki bo izdan kot odgovor na <i>poll ()<\/i>. Klju\u010dno pri branju je trenutek, ko se ta odmik pove\u010duje.<\/p>\n<p>Vrnjeni k modelu branja, obravnavanemu prej, obdelava sporo\u010dila sestavlja tri korake:<\/p>\n<ol>\n<li>Izvle\u010di sporo\u010dilo za branje.<\/li>\n<li>Obdelati sporo\u010dilo.<\/li>\n<li>Potrditev sporo\u010dila.<\/li>\n<\/ol>\n<p>\nKafka potro\u0161nik prihaja z mo\u017enostjo konfiguracije <i>enable.auto.commit<\/i>. To je pogosto uporabljena privzeta nastavitev, kot je obi\u010dajno pri nastavitvah, ki vsebujejo besedo 'avto'.<\/p>\n<p>Pred Kafka 0.10 je stranka, ki je uporabljala to mo\u017enost, poslala odmik zadnjega prebranega sporo\u010dila pri naslednjem klicu <i>poll ()<\/i> po obdelavi. To je pomenilo, da so lahko bila vsa sporo\u010dila, ki so bila \u017ee izvle\u010dena, ponovno obdelana, \u010de jih je stranka \u017ee obdelala, vendar je bila nepri\u010dakovano uni\u010dena pred klicem <i>poll ()<\/i>. Ker broker ne shrani nobene informacije o tem, kolikokrat je bilo sporo\u010dilo prebrano, naslednji potro\u0161nik, ki to sporo\u010dilo pridobi, ne bo vedel, da se je zgodilo kaj slabega. To vedenje je bilo pseudo-transakcijsko. Premik se je potrdil le, \u010de je bilo sporo\u010dilo uspe\u0161no obdelano, vendar \u010de je stranka prekinila delo, je broker isto sporo\u010dilo ponovno poslal drugemu stroju. To vedenje je ustrezalo garanciji dostave sporo\u010dil.<i>'vsaj enkrat'<\/i>&#171;.<\/p>\n<p>V Kafka 0.10 je bil koda stranke spremenjena tako, da se je komit periodi\u010dno izvajal s strani knji\u017enice stranke, v skladu z nastavitvijo <i>auto.commit.interval.ms<\/i>. To vedenje se nahaja nekje med na\u010dini JMS AUTO_ACKNOWLEDGE in DUPS_OK_ACKNOWLEDGE. Pri uporabi avtokomita so lahko bila sporo\u010dila potrjena ne glede na to, ali so bila dejansko obdelana \u2014 to se je lahko zgodilo v primeru po\u010dasnega potro\u0161nika. \u010ce je potro\u0161nik prekinil delo, so sporo\u010dila bila izvle\u010dena naslednjim potro\u0161nikom, za\u010den\u0161i s potrjeno pozicijo, kar je lahko povzro\u010dilo, da je sporo\u010dilo manjkalo. V tem primeru Kafka ni izgubila sporo\u010dil, kod, ki bere, jih preprosto ni obdelal.<\/p>\n<p>Ta na\u010din ima enake perspektive kot v razli\u010dici 0.9: sporo\u010dila so lahko obdelana, vendar v primeru okvare, odmik morda ni bil potrjen, kar potencialno lahko vodi do podvajanja dostave. Ve\u010d sporo\u010dil kot izvle\u010dete pri izvajanju <i>poll ()<\/i>, ve\u010dja bo ta te\u017eava.<\/p>\n<p>Kot je obravnavano v razdelku \u201eBralni sporo\u010dil iz \u010dakalne vrste\u201c na strani 21, v sistemu za izmenjavo sporo\u010dil ne obstaja koncept enkratne dostave sporo\u010dila, \u010de upo\u0161tevamo pogoje napak.<\/p>\n<p>V Kafki obstajata dva na\u010dina za zabele\u017eitev (potrditev) offseta: samodejno in ro\u010dno. V obeh primerih je mo\u017eno, da se sporo\u010dila obdelajo ve\u010dkrat, \u010de je bilo sporo\u010dilo obdelano, vendar je pri\u0161lo do napake pred potrditvijo. Prav tako lahko sporo\u010dila sploh ne obdelate, \u010de je bila potrditev opravljena v ozadju, predno se va\u0161a koda za\u010dne obdelovati (morda v Kafki 0.9 in starej\u0161ih razli\u010dicah).<\/p>\n<p>Rokovanje s postopkom potrjevanja offseta je lahko ro\u010dno v API-ju porabnika Kafke z nastavitvijo parametra <i>enable.auto.commit<\/i> na false in z izrecnim klicem ene od naslednjih metod:<\/p>\n<pre><code class=\"java\">void commitSync();\nvoid commitAsync();<\/code><\/pre>\n<p>\n\u010ce \u017eelite obdelati sporo\u010dilo \u201evsaj enkrat\u201c, morate ro\u010dno potrditi offset z uporabo <i>commitSync()<\/i>, tako da to naslednjo ukaz izvedete takoj po obdelavi sporo\u010dil.<\/p>\n<p>Te metode ne omogo\u010dajo potrjevanja (acknowledged) sporo\u010dil, preden so obdelana, vendar ne re\u0161ujejo mogo\u010de podvajanja obdelave, hkrati pa ustvarjajo videz transakcijskosti. V Kafki ni transakcij. Stranka nima mo\u017enosti narediti naslednjega:<\/p>\n<ul>\n<li>Samodejno preklicati (roll back) neuspelo sporo\u010dilo. Porabniki morajo sami obravnavati izjeme, ki nastanejo zaradi problemati\u010dnih payloadov in izklopov backend-a, saj ne morejo zaupati ponovni dostavi sporo\u010dil s strani posrednika.<\/li>\n<li>Po\u0161iljati sporo\u010dila v ve\u010d tematskih sklopih v okviru ene atomske operacije. Kot bomo kmalu videli, lahko nadzor nad razli\u010dnimi tematskimi sklopi in particijami ostane na razli\u010dnih napravah v Kafkinem klasterju, ki ne usklajujejo transakcij pri po\u0161iljanju. Ob \u010dasu pisanja tega \u010dlanka je bilo narejenega nekaj dela, da bi to omogo\u010dili s KIP-98.<\/li>\n<li>Povezati branje enega sporo\u010dila iz enega tematskega sklopa s po\u0161iljanjem drugega sporo\u010dila v drug tematski sklop. Spet, arhitektura Kafke temelji na \u0161tevilnih neodvisnih napravah, ki delujejo kot en sistem in ne posku\u0161ajo skriti te povezanosti. Na primer, ne obstajajo API komponente, ki bi omogo\u010dale povezovanje <i>Porabnika <\/i>in <i>Producenta <\/i>v transakciji. V JMS to zagotavlja objekt <i>Session<\/i>, iz katerega se ustvarjajo <i>MessageProducers <\/i>in <i>MessageConsumers<\/i>.<\/li>\n<\/ul>\n<p>\n\u010ce se ne moremo zana\u0161ati na transakcije, kako lahko zagotovimo semantiko, ki je bli\u017eje tisti, ki jo zagotavljajo tradicionalni sistemi za izmenjavo sporo\u010dil?<\/p>\n<p>\u010ce obstaja verjetnost, da se lahko offset potro\u0161nika pove\u010da pred obdelavo sporo\u010dila, na primer v primeru okvare potro\u0161nika, potem potro\u0161nik nima na\u010dina, da bi vedel, ali je njegova skupina potro\u0161nikov pri dodeljevanju particije presko\u010dila sporo\u010dila. Tako je ena od strategij, da se offset pomakne (rewind) na prej\u0161njo pozicijo. Kafka API potro\u0161nika ponuja naslednje metode za to:<\/p>\n<pre><code class=\"java\">void seek(TopicPartition partition, long offset);\nvoid seekToBeginning(Collection  partitions);<\/code><\/pre>\n<p>\nMetod <i>seek ()<\/i> lahko se uporablja z metodo <br \/>\n<i>offsetsForTimes (Map timestampsToSearch)<\/i> za pomik v stanje v nekem dolo\u010denem trenutku v preteklosti.<\/p>\n<p>Neposredno, uporaba tega pristopa pomeni, da je zelo verjetno, da bodo nekatera sporo\u010dila, ki so bila prej obdelana, ponovno prebrana in obdelana. Da bi se temu izognili, lahko uporabimo idempotentno branje, kot je opisano v Poglavju 4, za sledenje prej pregledanim sporo\u010dilom in izklju\u010ditev podvojitev.<\/p>\n<p>Alternativno lahko koda va\u0161ega potro\u0161nika ostane preprosta, \u010de je izguba ali podvajanje sporo\u010dil sprejemljivo. Ko razmi\u0161ljamo o scenarijih, v katerih se obi\u010dajno uporablja Kafka, na primer, obdelava dogodkov dnevnikov, metrik, sledenje klikom itd., razumemo, da bo izguba posameznih sporo\u010dil verjetno imela malo pomembnega vpliva na sosednje aplikacije. V takih primerih so privzete vrednosti povsem sprejemljive. Po drugi strani, \u010de va\u0161e aplikacije potrebujejo prenos pla\u010dil, morate skrbno obravnavati vsako posamezno sporo\u010dilo. Vse se vrti okoli konteksta.<\/p>\n<p>Osebne opazke ka\u017eejo, da z nara\u0161\u010danjem intenzivnosti sporo\u010dil vrednost vsakega posameznega sporo\u010dila upada. Sporo\u010dila velikega obsega postanejo obi\u010dajno dragocena, \u010de jih obravnavamo v agregirani obliki.<\/p>\n<h2>Visoka razpolo\u017eljivost (High Availability)<\/h2>\n<p>\nKafka pristop za visoko razpolo\u017eljivost se znatno razlikuje od pristopa ActiveMQ. Kafka je zasnovana na horizontalno skalabilnih grozdi, kjer vsi primerki posrednika hkrati sprejemajo in po\u0161iljajo sporo\u010dila.<\/p>\n<p>Grozdi Kafka sestavljajo \u0161tevilni primerki posrednika, ki delujejo na razli\u010dnih stre\u017enikih. Kafka je bila zasnovana za delovanje na obi\u010dajni samostojni strojni opremi, kjer ima vsaka vozli\u0161\u010de svoj lastni dodeljeni prostor za shranjevanje. Uporaba omre\u017enih shranjevanj (SAN) ni priporo\u010dljiva, saj lahko \u0161tevilni ra\u010dunalni\u0161ki vozli konkurirajo za obdobja shranjevanja in ustvarjajo konflikte.<i>\u042b<\/i>Kafka je<\/p>\n<p>nenehno aktivirana <i>sistem. Mnogi veliki uporabniki Kafke nikoli ne izklopijo svojih grozdov in programska oprema vedno zagotavlja posodobitev z zaporednim ponovnim zagonom. To se dose\u017ee z zagotavljanjem zdru\u017eljivosti s prej\u0161njimi razli\u010dicami sporo\u010dil in interakcijami med posredniki.<\/i> Posredniki so povezani z grozdom stre\u017enikov<\/p>\n<p>ZooKeeper <noindex><a rel=\"nofollow\" href=\"http:\/\/zookeeper.apache.org\">, ki deluje kot registrov konfiguracijskih podatkov in se uporablja za usklajevanje vlog vsakega posrednika. ZooKeeper je sama distribuirana sistem, ki zagotavlja visoko razpolo\u017eljivost z replikacijo informacij s pomo\u010djo vzpostavitve<\/a><\/noindex>kvora. <i>V osnovnem primeru se tema ustvari v grozdu Kafka z naslednjimi lastnostmi:<\/i>.<\/p>\n<p>\u0160tevilo particij. Kot je bilo prej omenjeno, natan\u010dna vrednost, ki se tu uporablja, dolo\u010da \u017eeleni nivo paralelnega branja.<\/p>\n<ul>\n<li>Dele\u017e (faktor) replikacije dolo\u010da, koliko primerkov posrednika v grozdu mora vsebovati dnevnike za to particijo.<\/li>\n<li>Z uporabo ZooKeeperja za usklajevanje, Kafka posku\u0161a po\u0161teno razdeliti nove particije med posrednike v grozdu. To stori en primerek, ki opravlja vlogo kontrolerja.<\/li>\n<\/ul>\n<p>\nMed izvajanjem<\/p>\n<p>vsaki particiji teme <i>dodeli posredniku vloge<\/i> <i>Krmilnik <\/i>vodje <i>(leader, master, vodilni) in <\/i>sledilcev. <i>sledbenika <\/i>(followers, slaves, podre\u0111eni). Broker koji djeluje kao vo\u0111a za ovu particiju odgovara za primanje svih poruka koje mu \u0161alju producenti i za distribuciju poruka potro\u0161a\u010dima. Kada se \u0161alju poruke u particiju teme, one se repliciraju na sve nodove brokera koji su trenutni za ovu particiju. Svaki nod koji sadr\u017ei logove za particiju naziva se <i>replikom<\/i>. Broker mo\u017ee biti vo\u0111a za neke particije, dok za druge mo\u017ee biti sledbenik.<\/p>\n<p>Sledbenik koji sadr\u017ei sve poruke koju \u010duva vo\u0111a naziva se <i>sinhronizovana replika<\/i> (replika koja je u sinhronizovanom stanju, in-sync replica). Ako se broker koji je vo\u0111a za particiju isklju\u010di, bilo koji broker koji je a\u017euriran ili sinhronizovan za ovu particiju mo\u017ee preuzeti ulogu vo\u0111e. Ovo je izuzetno otporan dizajn.<\/p>\n<p>Deo konfiguracije producenta je parametar <i>acks<\/i>, koji defini\u0161e koliko replik mora potvrditi (acknowledge) prijem poruke pre nego \u0161to aplikacioni tok nastavi sa slanjem: 0, 1 ili sve. Ako je postavljena vrednost <i>all<\/i>, tada \u0107e prilikom primanja poruke vo\u0111a poslati potvrdu (confirmation) nazad producentu \u010dim primi potvrde (acknowledgements) zapisa od vi\u0161e replik (uklju\u010duju\u0107i i sebe), kako je odre\u0111eno pode\u0161avanjem teme <i>min.insync.replicas<\/i> (podrazumevano 1). Ako poruku nije mogu\u0107e uspe\u0161no replicirati, producent \u0107e pokrenuti izuzetak za aplikaciju (<i>NotEnoughReplicas<\/i> ili <i>NotEnoughReplicasAfterAppend<\/i>).<\/p>\n<p>U tipi\u010dnoj konfiguraciji kreira se tema sa faktorom replike 3 (1 vo\u0111a, 2 sledbenika za svaku particiju) i parametar <i>min.insync.replicas<\/i> se postavlja na vrednost 2. U tom slu\u010daju, klaster \u0107e dozvoliti da jedan od brokera koji upravljaju particijom teme mo\u017ee biti isklju\u010den bez uticaja na klijentske aplikacije.<\/p>\n<p>Ovo nas vra\u0107a na ve\u0107 poznati kompromis izme\u0111u performansi i pouzdanosti. Replikacija se de\u0161ava zbog dodatnog vremena \u010dekanja potvrda (acknowledgments) od sledbenika. Iako se vr\u0161i paralelno, replikacija, barem na tri nodova, ima istu performansu kao i na dva (zanemaruju\u0107i pove\u0107anu potro\u0161nju mre\u017enog propusta).<\/p>\n<p>Z uporabo te replicirne sheme Kafka spretno prepre\u010duje potrebo po fizi\u010dnem zapisovanju vsakega sporo\u010dila na disk prek operacije <i>sync ()<\/i>. Vsako sporo\u010dilo, poslano od proizvajalca, bo zabele\u017eeno v dnevniku particije, vendar, kot je razpravljano v Poglavju 2, se zapis v datoteko sprva izvede v predpomnilnik operacijskega sistema. \u010ce je to sporo\u010dilo replicirano na drugo instanco Kafke in je v njenem pomnilniku, izguba vodje ne pomeni, da je samo sporo\u010dilo izgubljeno \u2014 to lahko prevzame sinhronizirana replika.<br \/>\nOpustitev potrebe po izvajanju operacije <i>sync ()<\/i> pomeni, da lahko Kafka sprejema sporo\u010dila s hitrostjo, s katero jih lahko zapisuje v pomnilnik. In obratno, \u010dim dlje se lahko izognemo spro\u0161\u010danju (flushing) pomnilnika na disk, tem bolje. Iz tega razloga ni redkost, da brokerjem Kafke dodelijo 64 GB pomnilnika ali ve\u010d. Tak\u0161na uporaba pomnilnika pomeni, da lahko ena instanca Kafke zlahka deluje s hitrostmi, ki so tiso\u010dkrat hitrej\u0161e od tradicionalnega posrednika sporo\u010dil.<\/p>\n<p>Kafko je mogo\u010de tudi konfigurirati za uporabo operacije <i>sync ()<\/i> na paketih sporo\u010dil. Ker je vse v Kafki zasnovano za delo s paketi, to dejansko dobro deluje za mnoge scenarije uporabe in je uporabno orodje za uporabnike, ki zahtevajo zelo mo\u010dne garancije. Ve\u010dino \u010diste zmogljivosti Kafke je povezane s sporo\u010dili, ki se po\u0161iljajo brokerju v obliki paketov, in s tem, da se ta sporo\u010dila berejo iz brokerja po zaporednih blokih z uporabo <noindex><a rel=\"nofollow\" href=\"http:\/\/www.linuxjournal.com\/article\/6345\">zero-copy<\/a><\/noindex> operacij (operacij, pri katerih ni zakasnitev pri kopiranju podatkov iz enega podro\u010dja pomnilnika v drugega). Zadnja to\u010dka prina\u0161a velik dobi\u010dek z vidika zmogljivosti in virov in je mogo\u010da le s pomo\u010djo osnovne strukture podatkov dnevnika, ki dolo\u010da shemo particije.<\/p>\n<p>V klastru Kafke je mogo\u010da precej vi\u0161ja zmogljivost, kot pri uporabi enega brokera Kafke, saj se particije teme lahko horizontalno skalirajo na \u0161tevilnih lo\u010denih strojih.<\/p>\n<h2>Zaklju\u010dki<\/h2>\n<p>\nV tem poglavju smo preu\u010dili, kako arhitektura Kafka preoblikuje odnose med odjemalci in posredniki, da zagotovi izjemno odporen sistem za izmenjavo sporo\u010dil z zmogljivostjo, ki ve\u010dkrat presega obi\u010dajnega posrednika sporo\u010dil. Razpravljali smo o funkcionalnosti, ki jo uporablja za dosego tega cilja, in na kratko preu\u010dili arhitekturo aplikacij, ki zagotavljajo to funkcionalnost. V naslednjem poglavju bomo preu\u010dili splo\u0161ne izzive, ki jih morajo re\u0161evati aplikacije na osnovi izmenjave sporo\u010dil, ter razpravljali o strategijah za re\u0161evanje teh izzivov. Poglavje bomo zaklju\u010dili s slikovitim prikazom, kako razmi\u0161ljati o tehnologijah izmenjave sporo\u010dil na splo\u0161no, da boste lahko ocenili njihovo primernost za va\u0161e scenarije uporabe.<\/p>\n<p>Prej\u0161nji prevedeni del: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">Razumevanje posrednikov sporo\u010dil. Razi\u0161\u010dite mehaniko izmenjave sporo\u010dil prek ActiveMQ in Kafka. Poglavje 1<\/a><\/noindex><\/p>\n<p><b> Prevod izvr\u0161en: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p><i>Nadaljujte&#8230;<\/i><\/p>\n<p class=\"for_users_only_msg\">Samo registrovani korisnici mogu u\u010destvovati u anketi. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Prijavite se<\/a><\/noindex>, molim vas.<\/p>\n<h2 class=\"default-block__polling-title\">Ali va\u0161a organizacija uporablja Kafka?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Da<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ne<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Prej smo jo uporabljali, zdaj ne ve\u010d<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Na\u010drtujemo uporabo<\/p>\n<\/li>\n<\/ul>\n<p>    38 uporabnikov je glasovalo. 8 uporabnikov se je vzdr\u017ealo.<br \/>\n<br \/>Izvor: <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.4 - 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\/sl\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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\udd47Razumevanje posrednikov sporo\u010dil. Preu\u010devanje mehanike izmenjave sporo\u010dil preko ActiveMQ in Kafka. Poglavje 3. Kafka | ProHoster","description":"Nadaljevanje prevoda knjige: \u00abUnderstanding Message Brokers\u00bb, avtor: Jakub Korab, zalo\u017eba: O'Reilly Media, Inc., datum izdaje: junij 2017, ISBN: 9781492049296. Prej prevedeno.","canonical_url":"https:\/\/prohoster.info\/sl\/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":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/38172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=38172"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/38172\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=38172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=38172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=38172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}