{"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\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Raamatuke t\u00f5lkimise j\u00e4tk:<br \/>\n\u00abUnderstanding Message Brokers\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\u00f5numi 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 m\u00f5ningaid traditsiooniliste s\u00f5numite edastamise piire ja v\u00e4ltida vajadust konfigureerida erinevaid s\u00f5numite edastamise vahendeid erinevatele 'punkt-punkt' interaktsioonidele, nagu on kirjeldatud selles raamatus peat\u00fckis 'Vertikaalne ja horisontaalne skaleerimine' lehek\u00fcljel 28. LinkedInis p\u00f5hines kasutusstsenaarium peamiselt v\u00e4ga suurte andmehulkade \u00fchesuunalisel omastamisel, nagu lehtede klikkide ja logide eemaldamine, samas lubades mitme s\u00fcsteemi samaaegset andmete kasutamist, m\u00f5jutamata tootjate v\u00f5i teiste tarbijate j\u00f5udlust. Tegelikult on Kafka olemasolu p\u00f5hjus sellise s\u00f5numite vahetamise arhitektuuri saavutamine, nagu kirjeldab Universal Data Pipeline.<\/p>\n<p>Selle l\u00f5ppeesm\u00e4rgi t\u00f5ttu on loomulik, et tekkisid ka teised n\u00f5uded. Kafka peab:<\/p>\n<ul>\n<li>Oleme \u00e4\u00e4rmiselt kiire<\/li>\n<li>Tagama suure ribalaiuse s\u00f5numite t\u00f6\u00f6tlemisel<\/li>\n<li>Toetama 'K\u00fc\u00fcrija-Tellija' ja 'Punkt-Punkt' mudeleid<\/li>\n<li>\u00c4rge viivitage tarbijate lisamisega. N\u00e4iteks, ActiveMQ j\u00f5udlus ja j\u00e4rjekorrad halvenevad, kui adressaadil on liiga palju tarbijaid.<\/li>\n<li>Olge horisontaalselt skaleeritav; kui \u00fcks s\u00f5numite vahetaja suudab s\u00f5numeid talletada (persists) ainult \u00fclikiirusel, siis on m\u00f5ttekas \u00fcletada \u00fche vahetaja eksemplari piirid, et suurendada j\u00f5udlust.<\/li>\n<li>Piirake juurdep\u00e4\u00e4su s\u00f5numite talletamisele ja uuesti v\u00e4ljav\u00f5tmisest.<\/li>\n<\/ul>\n<p>\nSelle saavutamiseks on Kafka's kasutusele v\u00f5etud arhitektuur, mis on \u00fcmber defineerinud klientide ja s\u00f5numivahetuse maaklerite rollid ja kohustused. JMS-i mudel on v\u00e4ga maaklerikeskne, kus maakler vastutab s\u00f5numite edastamise eest, samas kui kliendid peavad muretsema vaid s\u00f5numite saatmise ja vastuv\u00f5tmise \u00fcle. Kafka, vastupidiselt, on klientide keskne, kus klient v\u00f5tab enda kanda paljusid traditsioonilise maakleri funktsioone, nagu n\u00e4iteks asjakohaste s\u00f5numite \u00f5iglane jaotamine tarbijate vahel, saades selle eest \u00e4\u00e4rmiselt kiire ja skaleeritava maakleri. Inimestele, kes on t\u00f6\u00f6tanud traditsiooniliste s\u00f5numivahetuss\u00fcsteemidega, n\u00f5uab t\u00f6\u00f6 Kafka'ga fundamentaalset muutust arusaamades.<br \/>\nSee inseneritegevus viis loodud s\u00f5numivahetusinfrastruktuuri, mis suudab v\u00f5rreldes tavap\u00e4raste maakleritega paljude m\u00f5\u00f5tmete v\u00f5rra suurendada l\u00e4bilaskev\u00f5imet. Nagu me n\u00e4eme, on see l\u00e4henemine seotud kompromissidega, mis t\u00e4hendavad, et Kafka ei sobi teatud t\u00fc\u00fcpi koormuste ja paigaldatud tarkvara jaoks.<\/p>\n<h3>\u00dchtne sihtm\u00e4rkide mudel<\/h3>\n<p>\nKohustuste t\u00e4itmiseks, nagu eespool kirjeldatud, on Kafka \u00fchendatud \"v\u00e4ljaande-telli\" ja \"punkt-punkt\" s\u00f5numivahetuse vaheline mehhanism \u00fche adressaadiga \u2014 <i>teema<\/i>. See tekitab segadust inimestes, kes on t\u00f6\u00f6tanud s\u00f5numivahetuss\u00fcsteemidega, kus s\u00f5na \"teema\" viitab laiemale mehhanismile, mille kaudu (teemast) lugemine ei ole usaldusv\u00e4\u00e4rne (on mittep\u00fcsiv). Kafka teemasi tuleks k\u00e4sitleda h\u00fcbriidse adressaadina, vastavalt m\u00e4\u00e4ratlusele, mis on antud selle raamatu sissejuhatuses.<\/p>\n<blockquote><p>Selle peat\u00fcki \u00fclej\u00e4\u00e4nud osas, kui me ei osuta selgelt teisiti, viitab termin \"teema\" Kafka teemale.<\/p><\/blockquote>\n<p>\nSelleks, et t\u00e4ielikult m\u00f5ista, kuidas teemad k\u00e4ituvad ja milliseid garantiisid nad pakuvad, peame esmalt vaatama, kuidas nad on Kafka-s rakendatud.<br \/>\n<i>Igal teemal Kafka-s on oma logi.<\/i><br \/>\nProducers sending messages to Kafka append to this log, while consumers read from the log using pointers that continually move forward. Periodically, Kafka deletes the oldest parts of the log, regardless of whether the messages in those parts have been read or not. A central aspect of Kafka's design is that the broker does not care whether messages have been read \u2014 that is the client's responsibility.<\/p>\n<blockquote><p>The terms \"log\" and \"pointer\" do not appear in <noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation.html\">the Kafka documentation<\/a><\/noindex>. These well-known terms are used here to aid understanding.<\/p><\/blockquote>\n<p>\nThis model is fundamentally different from ActiveMQ, where messages from all queues are stored in a single log, and the broker marks messages as deleted after they have been read.<br \/>\nNow let's delve a bit deeper and examine the topic's log in more detail.<br \/>\nThe Kafka log consists of several partitions (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/tm\/w2\/yf\/tmw2yf3lanppqtrumxoidotplhi.png\">Figure 3-1<\/a><\/noindex>). Kafka tagab igas partitsioonis ranget j\u00e4rjestust. See t\u00e4hendab, et partitsiooni teatud j\u00e4rjekorras salvestatud s\u00f5numid loetakse samas j\u00e4rjekorras. Iga partitsioon on ellu kutsutud ringikujulise (rolling) logifailina, mis sisaldab <i>alamkogumi <\/i>(subset) k\u00f5igist s\u00f5numitest, mida tema tootjad teema peale saadavad. Uus teema sisaldab vaikimisi \u00fchte partitsiooni. Partitsioonide idee on Kafka keskne m\u00f5te horisontaalsest skaleerimisest.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse 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 partitsioonid<\/i><\/p>\n<p>Kui tootja saadab s\u00f5numi Kafka teemasse, otsustab ta, millisesse partitsioonisse s\u00f5num saata. Me k\u00e4sitleme seda \u00fcksikasjalikumalt hiljem.<\/p>\n<h2>S\u00f5numite lugemine<\/h2>\n<p>\nKliendil, kes soovib s\u00f5numeid lugeda, on hallatav nimeline osutaja, mida nimetatakse <i>tarbijate r\u00fchm (consumer group)<\/i>, mis osutab <i>asendile (offset)<\/i> s\u00f5numis partitsioonis. Asend on suureneva numbriga positsioon, mis algab partitsiooni alguses 0-st. See tarbijate r\u00fchm, millele viidatakse API-s l\u00e4bi m\u00e4\u00e4ratletud kasutaja identifikaatori group_id, vastab <i>\u00fchele loogilisele tarbijale v\u00f5i s\u00fcsteemile<\/i>.<\/p>\n<p>Enamik s\u00f5numivahetuss\u00fcsteeme loevad andmeid adressaadilt mitme eksemplari ja voogude kaudu paralleelsete s\u00f5numite t\u00f6\u00f6tlemiseks. Seet\u00f5ttu on tavaliselt palju konsuumerite eksemplare, mis jagavad sama konsuumerigruppi.<\/p>\n<p>Lugemise probleem esitatakse j\u00e4rgmiselt:<\/p>\n<ul>\n<li>Teemal on mitu jaotust<\/li>\n<li>Teemat saavad korraga kasutada mitmed konsuumerigruppid<\/li>\n<li>Konsuumerigrupp v\u00f5ib sisaldada mitmeid eraldi eksemplare<\/li>\n<\/ul>\n<p>\nSee on mittetriviaalne probleem \"palju-palju\". Selleks et m\u00f5ista, kuidas Kafka k\u00e4sitleb suhete vahel konsuumerigruppide, konsuumerite ja jaotuste vahel, vaatame mitmeid j\u00e4rjest keerukamaid lugemise stsenaariume.<\/p>\n<h3>Konsuumerid ja konsuumerigruppid<\/h3>\n<p>\nV\u00f5tame l\u00e4htepunktiks teema, millel on \u00fcks jaotus (<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\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse 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. Konsuumer loeb jaotusest<\/i><\/p>\n<p>Kui tarbija eksemplar \u00fchendatakse oma grupi ID-ga sellele teemale, m\u00e4\u00e4ratakse talle lugemiseks partitsioon ja nihke positsioon selles partitsioonis. Selle nihke positsiooni seadistatakse kliendis, et see viitaks kas k\u00f5ige uuemale positsioonile (k\u00f5ige v\u00e4rskem s\u00f5num) v\u00f5i k\u00f5ige varasemale positsioonile (k\u00f5ige vanem s\u00f5num). Tarbija k\u00fcsib (polls) s\u00f5numeid teemalt, mis viib nende j\u00e4rjestikuse lugemiseni ajaloost.<br \/>\nNihke positsioon kommitakse regulaarselt tagasi Kafka-sse ja salvestatakse nagu s\u00f5numid sise-teemas <i>_consumer_offsets<\/i>. Loe s\u00f5numid ei kustutata, erinevalt tavalisest maaklerist, ja klient v\u00f5ib nihke tagasi kerida (rewind), et uuesti t\u00f6\u00f6delda juba vaadatud s\u00f5numeid.<\/p>\n<p>Kui teine loogiline tarbija \u00fchendatakse, kasutades teist grupi ID-d, haldab see teist n\u00e4idikut, 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 j\u00e4rjekord, kus on \u00fcks tarbija ja nagu tavaline v\u00e4ljaande-immuunsus (pub-sub), millele on \u00fchendatud mitu tarbijat, lisaks eelisele, et k\u00f5ik s\u00f5numid salvestatakse ja neid saab t\u00f6\u00f6delda mitu korda.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse 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>Joonis 3-3. Kaks tarbijat erinevates tarbijagruppides loevad \u00fchest partitsioonist<\/i><\/p>\n<h3>Tarbija grupis<\/h3>\n<p>\nKui \u00fcks tarbijainstants loeb andmeid partitsioonist, kontrollib ta t\u00e4ielikult n\u00e4idikut ja t\u00f6\u00f6tleb s\u00f5numeid nagu eelnevas osas kirjeldatud.<br \/>\nKui mitu tarbijainstantsi on sama group_id-ga topikutega \u00fche partitsiooniga \u00fchendatud, antakse viimase \u00fchendatud instantsi kontroll n\u00e4idiku \u00fcle ja alates sellest hetkest hakkab see saama k\u00f5ik s\u00f5numid (<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\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse 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 tarbijat samas tarbijagruppis loevad \u00fchest partitsioonist<\/i><\/p>\n<p>Seda t\u00f6\u00f6tlemisre\u017eiim, kus tarbijaid on rohkem kui jaotusi, v\u00f5ib pidada monopoltarbimiseks. See v\u00f5ib olla kasulik, kui vajate oma tarbijate \u201eaktiivset-passiivset\u201d (v\u00f5i \u201esoe-k\u00fclm\u201d) klasterdamist, kuigi mitme tarbija samal ajal t\u00f6\u00f6tamine (\u201eaktiivne-aktiivne\u201d v\u00f5i \u201esoe-soe\u201d) on oluliselt tavalisem kui ootere\u017eiimis olevad tarbijad.<\/p>\n<blockquote><p>\u00dclaltoodud s\u00f5numite jaotuse k\u00e4itumine v\u00f5ib olla \u00fcllatav v\u00f5rreldes tavalise JMS-j\u00e4rjekorra k\u00e4itumisega. Selles mudelis jaotatakse j\u00e4rjekorda saadetud s\u00f5numid v\u00f5rdselt kahe tarbija vahel.<\/p><\/blockquote>\n<p>\nK\u00f5ige sagedamini, kui me loome mitu tarbijate eksemplari, teeme seda kas s\u00f5numite paralleelse t\u00f6\u00f6tlemise, lugemise kiiruset\u00f5usu v\u00f5i lugemisprotsessi vastupidavuse suurendamise nimel. Kuna andmeid v\u00f5ib jaotisest lugeda samaaegselt ainult \u00fcks tarbija eksemplar, siis kuidas seda Kafka-s saavutatakse?<\/p>\n<p>\u00dcks viise seda teha on kasutada \u00fchte konsumerit, et lugeda k\u00f5iki s\u00f5numeid ja edastada need thread pooli. Kuigi see l\u00e4henemine suurendab t\u00f6\u00f6tlemise l\u00e4bilaskev\u00f5imet, muudab see konsumerite loogika keerukamaks ning ei aita \u00fcldse s\u00fcsteemi lugemise vastupidavust parandada. Kui \u00fcks konsumeri eksemplar v\u00e4lja l\u00fclitatakse toitekatkestuse v\u00f5i sarnase s\u00fcndmuse t\u00f5ttu, siis lugemine peatub.<\/p>\n<p>Selle probleemi kanoniline lahendus Kafkas on kasutada rohkemat<i>Umbes<\/i>partitsioonide.<\/p>\n<h3>Partitsionimine<\/h3>\n<p>\nPartitsioonid on peamine mehhanism lugemise paralleelseteks jagamiseks ja teema skaleerimiseks \u00fche brokeri l\u00e4bilaskev\u00f5imet \u00fcletavateks. Selle parema m\u00f5istmiseks vaatame olukorda, kus on teema, millel on kaks partitsiooni ja sellele teemale on tellinud \u00fcks konsumer (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/en\/9g\/ct\/en9gct0o017cqp8buawguwlscty.png\">Figure 3-5<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse 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>Figure 3-5. \u00dcks konsumer loeb mitmest partitsioonist<\/i><\/p>\n<p>Selles stsenaariumis antakse konsumerile kontroll n\u00e4idikute \u00fcle, mis vastavad tema group_id-le m\u00f5lemas partitsioonis, ja lugemine algab m\u00f5lemast partitsioonist.<br \/>\nKui sellesse teema lisatakse sama group_id jaoks t\u00e4iendav tarbija, m\u00e4\u00e4rab Kafka \u00fche partitsiooni esimeselt teisele tarbijale \u00fcmber. P\u00e4rast seda loeb iga tarbija eksemplar \u00fchest partitsioonist teemad.<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/8b\/a0\/um\/8ba0umn2yzr9yy3vztonhdfiub0.png\">Kujutis 3-6<\/a><\/noindex>).<\/p>\n<p>Selleks, et tagada s\u00f5numite t\u00f6\u00f6tlemine paralleelselt 20 l\u00f5imes, vajate v\u00e4hemalt 20 partitsiooni. Kui partitsioone on v\u00e4hem, j\u00e4\u00e4vad teil tarbijad, kellel pole midagi teha, nagu oli varem arutatud monopolide tarbijatega.<\/p>\n<p><img decoding=\"async\" alt=\"S\u00f5numi vahendite m\u00f5istmine. S\u00f5numite vahetuse 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>Kujutis 3-6. Kaks tarbijat samas tarbijate grupis loevad erinevatest partitsioonidest<\/i><\/p>\n<p>See skeem v\u00e4hendab oluliselt Kafka vahendaja t\u00f6\u00f6 keerukust v\u00f5rreldes s\u00f5numite jaotamisega, mis on vajalik JMS j\u00e4rjekorra toetamiseks. Siin ei pea muretsema j\u00e4rgmiste punktide p\u00e4rast:<\/p>\n<ul>\n<li>Milline tarbija peaks saama j\u00e4rgmise s\u00f5numi, l\u00e4htudes ringja (round-robin) jaotamisest, praegustest eelt\u00e4item\u00e4lude mahtudest v\u00f5i eelmistest s\u00f5numitest (nagu JMS s\u00f5numigruppide puhul).<\/li>\n<li>Millised s\u00f5numid on saadetud millistele tarbijatele ja kas need tuleb edastada uuesti juhul, kui tekib rike.<\/li>\n<\/ul>\n<p>\nK\u00f5ik, mida Kafka broker peab tegema, on edastada s\u00f5numid tarbijale j\u00e4rjestikku, kui viimane neid k\u00fcsib.<\/p>\n<p>Kuid n\u00f5uded paralleelse lugemise ja eba\u00f5nnestunud s\u00f5numite uuesti saatmise osas ei kao kuskile - vastutus nende eest l\u00e4heb lihtsalt brokerilt kliendile. See t\u00e4hendab, et need tuleb teie koodis arvesse v\u00f5tta.<\/p>\n<h2>S\u00f5numite edastamine<\/h2>\n<p>\nOtsus selle kohta, millisesse partitsiooni s\u00f5num saata, lasub selle s\u00f5numi tootjal. Kuidas see mehhanism t\u00f6\u00f6tab, m\u00f5istmiseks tuleb esmalt uurida, mida me tegelikult saadame.<\/p>\n<p>Kui JMS-is kasutame me s\u00f5numistruktuuri koos metainformatsiooniga (pealkirjad ja omadused) ning kehaga, mis sisaldab koormust (payload), siis Kafka s\u00f5num on <i>v\u00f5ti-v\u00e4\u00e4rtus paar<\/i>. S\u00f5numi koormus saadetakse v\u00e4\u00e4rtusena (value). V\u00f5ti, omakorda, kasutatakse peamiselt partitsioneerimise jaoks ja peab sisaldama <i>\u00e4riloogika jaoks spetsiifilist v\u00f5tit<\/i>, et gruppeerida omavahel seotud s\u00f5numid samasse partitsiooni.<\/p>\n<p>II peat\u00fckis arutasime online-panuste stsenaariumi, kus seotud s\u00fcndmused tuleb t\u00f6\u00f6tleda j\u00e4rjestikku \u00fche tarbija poolt:<\/p>\n<ol>\n<li>Kasutajakonto on seadistatud.<\/li>\n<li>Raha kantakse kontole.<\/li>\n<li>Tehtud panus, mis t\u00f5mbab raha kontolt.<\/li>\n<\/ol>\n<p>\nKui iga s\u00fcndmus esindab s\u00f5numit, mis saadetakse teema, siis on loogiliseks v\u00f5tmeks kasutajakonto identifikaator.<br \/>\nKui s\u00f5num saadetakse Kafka Producer API kaudu, edastatakse see partitsioneerimise funktsioonile, mis arvestab s\u00f5numit ja hetkeolekut Kafka klastris, tagastab partitsiooni identifikaatori, kuhu s\u00f5num tuleks saata. See funktsioon on Java's rakendatud 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>\nParticionaatori realiseerimine, et m\u00e4\u00e4rata jaotust, kasutab vaikev\u00e4ljana v\u00f5tme hashring algoritmi (\u00fcldotstarbeline hash-algoritm v\u00f5tme jaoks) v\u00f5i ringj\u00e4tku (round-robin), kui v\u00f5ti ei ole m\u00e4\u00e4ratud. See vaikev\u00e4\u00e4rtus t\u00f6\u00f6tab suurep\u00e4raselt enamikul juhtudel. Tulevikus v\u00f5iksite siiski kirjutada oma versiooni.<\/p>\n<h3>Oma partitsioneerimisstrateegia kirjutamine<\/h3>\n<p>\nVaatame n\u00e4idet, kus soovite saata metainfot koos s\u00f5numi koormaga. Meie n\u00e4ite koormaks on juhis deposiidi tegemiseks m\u00e4ngukontole. Juhis on see, mida soovime tagada, et seda ei muudetaks edastamisel, ja soovime olla kindlad, et ainult usaldusv\u00e4\u00e4rne \u00fclemine s\u00fcsteem suudab seda juhist algatada. Sellisel juhul lepitakse saatmise ja vastuv\u00f5tmise s\u00fcsteemide vahel kokku allkirja kasutamises s\u00f5numi autentimise kontrollimiseks.<br \/>\nTavalisel JMS-is m\u00e4\u00e4rame lihtsalt \"s\u00f5numi allkirja\" omaduse ja lisame selle s\u00f5numile. Siiski ei paku Kafka mehaanismi metainformatsiooni edastamiseks \u2014 ainult v\u00f5tme ja v\u00e4\u00e4rtuse.<\/p>\n<p>Kuna v\u00e4\u00e4rtus on panga\u00fclekande koormus (bank transfer payload), mille terviklikkust soovime s\u00e4ilitada, ei j\u00e4\u00e4 meil muud valikut, kui m\u00e4\u00e4rata andmestruktuur, mida kasutada v\u00f5tmes. Eeldades, et vajame konto identifikaatorit andmete jagamiseks, kuna k\u00f5ik konto seonduvad s\u00f5numid peavad olema t\u00f6\u00f6delda j\u00e4rjestikuses j\u00e4rjekorras, m\u00f5tleme v\u00e4lja 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 j\u00e4rgi, ei suuda Partitioner'i vaikestrateegia usaldusv\u00e4\u00e4rselt r\u00fchmitada seondunud s\u00f5numeid. Seet\u00f5ttu peame kirjutama oma strateegia, mis anal\u00fc\u00fcsib seda v\u00f5tit ja jagab (partition) accountId v\u00e4\u00e4rtust.<\/p>\n<blockquote><p>Kafka sisaldab s\u00f5numite kahjustuse avastamiseks kontrollsummasid ja omab t\u00e4ielikku turvafunktsioonide komplekti. Siiski ilmnevad m\u00f5nikord spetsiifilised t\u00f6\u00f6stusn\u00f5uded, nagu eelnevalt mainitud.<\/p><\/blockquote>\n<p>\nKasutaja partitsioneerimisstrateegia peab tagama, et k\u00f5ik seotud s\u00f5numid j\u00e4\u00e4vad \u00fchte partitsiooni. Kuigi see n\u00e4ib olevat lihtne, v\u00f5ib n\u00f5ue keeruliseks osutuda, kuna on oluline s\u00e4ilitada seotud s\u00f5numite j\u00e4rjekord ja kui fikseeritud on partitsioonide arv teemas.<\/p>\n<p>Teema partitsioonide arv v\u00f5ib aja jooksul muutuda, kuna neid on v\u00f5imalik lisada, kui liiklus \u00fcletab esialgsed ootused. Seega v\u00f5ivad s\u00f5numite v\u00f5tmed olla seotud partitsiooniga, kuhu nad algselt saadeti, viidates osale olekust, mida tuleb jaotada tootja eksemplaride vahel.<\/p>\n<p>Teine aspekt, mida arvestada, on s\u00f5numite \u00fchtlane jaotumine partitsioonide vahel. \u00dcldiselt ei jaotata v\u00f5tmeid s\u00f5numite vahel \u00fchtlaselt, ja hash-funktsioonid ei garanteeri \u00f5iglast s\u00f5numite jaotumist v\u00e4ikese v\u00f5tmete komplekti jaoks.<br \/>\nOluline on m\u00e4rkida, et s\u00f5ltumata sellest, kuidas otsustate s\u00f5numeid jagada, v\u00f5ib osade eraldaja vajada korduvat kasutamist.<\/p>\n<p>Vaatame andmete replikatsiooni n\u00f5uet erinevates geograafilistes asukohtades asuvate Kafka klasterite vahel. Selleks on Kafka varustatud k\u00e4surea t\u00f6\u00f6riistaga nimega MirrorMaker, mida kasutatakse s\u00f5numite lugemiseks \u00fchest klastrist ja nende edastamiseks teise.<\/p>\n<p>MirrorMaker peab m\u00f5istma replitseeritava teema v\u00f5tmeid, et s\u00e4ilitada suhteline j\u00e4rjekord s\u00f5numite vahel, kuna selle teema partitsioonide arv v\u00f5ib kahes klastris erineda.<\/p>\n<p>Kohandatud partitsioneerimisstrateegiaid esineb suhteliselt harva, kuna vaikimisi hashimine v\u00f5i ts\u00fckliline jagamine t\u00f6\u00f6tab enamikus stsenaariumites edukalt. Siiski, kui vajate ranget j\u00e4rjekorra tagamist v\u00f5i peate laadimistest v\u00e4lja tooma metaandmeid, on partitsioneerimine see, millele peaksite rohkem t\u00e4helepanu p\u00f6\u00f6rama.<\/p>\n<p>Kafka skaleeritavuse ja j\u00f5udluse eelised tulenevad m\u00f5nede traditsiooniliste maaklerite kohustuste edasiviimisest kliendile. Sel juhul tehakse otsus potentsiaalselt seotud s\u00f5numite jaotamise kohta mitme samaaegselt t\u00f6\u00f6tava tarbija vahel.<\/p>\n<blockquote><p>JMS maaklerid peavad samuti nende n\u00f5uetega arvestama. Huvitav on see, et seotud s\u00f5numite saatmise mehhanism, mis on rakendatud l\u00e4bi JMS s\u00f5numigruppide (\u00fcks kleepuva koormuse tasakaalustamise (SLB) strateegia t\u00fc\u00fcp), n\u00f5uab samuti, et saatja m\u00e4rkiks s\u00f5numid kui seotud. JMS-i puhul vastutab maakler selle s\u00f5numigruppi kuuluva seotud s\u00f5numi saatmise eest \u00fche tarbija juurde paljude seast ja grupi omandi\u00f5iguse edastamise eest, kui tarbija katkeb.<\/p><\/blockquote>\n<p><\/p>\n<h2>Produtsendi kokkulepped<\/h2>\n<p>\nPartitsioneerimine ei ole ainus, mida tuleb arvesse v\u00f5tta s\u00f5numite saatmisel. Vaatame Java API klassi Producer meetodeid send ():<\/p>\n<pre><code class=\"java\">Future  send(ProducerRecord  record);\nFuture  send(ProducerRecord  record, Callback callback);<\/code><\/pre>\n<p>\nTuleb kohe m\u00e4rkida, et m\u00f5lemad meetodid tagastavad Future, mis viitab sellele, et saatmisoperatsioon ei toimu koheselt. Tulemuseks on see, et s\u00f5num (ProducerRecord) salvestatakse igale aktiivsele partitsioonile saatmispuppu ja edastatakse brokerile taustavoolus Kafka kliendi raamatukogus. Kuigi see teeb t\u00f6\u00f6tamise uskumatult kiireks, t\u00e4hendab see, et kehvasti kirjutatud rakendus v\u00f5ib s\u00f5numeid kaotada, kui selle protsess peatatakse.<\/p>\n<p>Nagu ikka, on v\u00f5imalus muuta saatmisoperatsioon usaldusv\u00e4\u00e4rsemaks, kuid selle arvel m\u00f5jutada j\u00f5udlust. Selle puhvri suurust saab seada nulliks ning saatva rakenduse voog peab ootama, kuni s\u00f5numi edastamine brokerile on l\u00f5pule viidud, nagu j\u00e4rgneb:<\/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 kaasa t\u00e4iendavaid keerukusi, millest tuleb arutleda. Erinevalt JMS API-st, mis v\u00f5ib k\u00e4ivitada s\u00f5numikuulaja (message listener) s\u00f5numi saabumisel, kasutab <i>Consumer <\/i>Kafka ainult k\u00fcsitakse (polling). Vaatame l\u00e4hemalt meetodit <i>poll ()<\/i>, mida selleks 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>on iseenesest v\u00f5tme-v\u00e4\u00e4rtuse paari hoidja objekt, millel on vastavad metaandmed, n\u00e4iteks partitsioon, kust see saadud on.<\/p>\n<p>Kuna arutatud teises peat\u00fckis, peame pidevalt meeles pidama, mis juhtub s\u00f5numitega p\u00e4rast nende eduka v\u00f5i ebaeduka t\u00f6\u00f6tlemise, n\u00e4iteks juhul kui klient ei saa s\u00f5numit t\u00f6\u00f6delda v\u00f5i katkestab t\u00f6\u00f6tamise. JMS-is k\u00e4sitleti seda kinnitamisre\u017eiimi kaudu. Broker kustutab kas edukalt t\u00f6\u00f6deldud s\u00f5numi v\u00f5i toimetab uuesti t\u00f6\u00f6tlemata v\u00f5i eba\u00f5nnestunud s\u00f5numi (eeldusel, et kasutati tehinguid). <br \/>\nKafka toimib t\u00e4iesti erinevalt. S\u00f5numeid ei kustutata brokrist p\u00e4rast lugemist ja vastutus selle eest, mis juhtub t\u00f5rke korral, lasub lugemisprotsessil endal.<\/p>\n<p>Kuna oleme juba \u00f6elnud, on tarbijate grupp seotud \u017eurnali nihkega. Nihkega seotud positsioon \u017eurnal vastab j\u00e4rgmisele s\u00f5numile, mis antakse v\u00e4lja vastusena <i>poll ()<\/i>. Ajal, mil see nihke suureneb, on lugemise jaoks m\u00e4\u00e4rava t\u00e4htsusega.<\/p>\n<p>Tagasi eelnevalt k\u00e4sitletud lugemisre\u017eiimi juurde, 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 konsumeril on konfigureerimise valik <i>enable.auto.commit<\/i>. See on sageli kasutatav vaikeasetus, nagu tavaliselt juhtub seadetega, mis sisaldavad s\u00f5na \"auto\".<\/p>\n<p>Enne Kafka 0.10 versiooni saatis klient, kes kasutas seda parameetrit, viimase 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\u00e4lja v\u00f5etud (fetched), v\u00f5idi uuesti t\u00f6\u00f6delda, kui klient oli need juba t\u00f6\u00f6tlenud, kuid h\u00e4vis ootamatult enne kutsumist. <i>poll ()<\/i>. Kuna maakler ei salvesta mingit olekut selle kohta, mitu korda s\u00f5numit on lugetud, ei tea j\u00e4rgmine tarbija, kes seda s\u00f5numit noppib, et midagi halba on juhtunud. See k\u00e4itumine oli pseudo-tehinguline. Nihketoiming registreeriti ainult juhul, kui s\u00f5numit \u00f5nnestus edukalt t\u00f6\u00f6delda, kuid kui klient katkestas t\u00f6\u00f6, saatis maakler sama s\u00f5numi teisele kliendile. Selline k\u00e4itumine vastas s\u00f5numite kohaletoimetamise garantii \"<i>v\u00e4hemalt kord<\/i>&#171;.<\/p>\n<p>Kafkas 0.10 muudeti kliendi koodi nii, et kinnitamine k\u00e4ivitati perioodiliselt klientide poolt vastavalt seadistusele <i>auto.commit.interval.ms<\/i>. See k\u00e4itumine asub kuskil JMS AUTO_ACKNOWLEDGE ja DUPS_OK_ACKNOWLEDGE re\u017eiimide vahel. Automaatkomite kasutamisel v\u00f5idi teadete t\u00f5en\u00e4oliselt kinnitada, s\u00f5ltumata sellest, kas need oli tegelikult t\u00f6\u00f6deldud - see v\u00f5is juhtuda aeglase tarbija t\u00f5ttu. Kui tarbija katkestas t\u00f6\u00f6, t\u00f5mmati teated j\u00e4rgmise tarbija poolt, alustades kinnitatud positsioonist, mis v\u00f5is p\u00f5hjustada teate varjamise. Sellisel juhul ei kaotanud Kafka teateid, lugemisprotsess lihtsalt ei t\u00f6\u00f6tlenud neid.<\/p>\n<p>See re\u017eiim omab samu perspektiive nagu versioonis 0.9: teated v\u00f5ivad olla t\u00f6\u00f6deldud, kuid t\u00f5rke korral ei pruugi positsiooni kinnitada, mis v\u00f5ib potentsiaalselt p\u00f5hjustada kahekordset saatmist. Mida rohkem teateid te t\u00f5mmate, kui <i>poll ()<\/i>, seda rohkem on see probleem.<\/p>\n<p>Nagu arutati jaotises 'Teadete lugemine j\u00e4rjekorrast' lk 21, ei ole s\u00f5numite edastamisel s\u00fcsteemis m\u00f5istet, nagu \u00fchekordne s\u00f5numite saatmine, kui arvesse v\u00f5tta t\u00f5rkeriske.<\/p>\n<p>Kafkas on kaks viisi nihke (offset) kinnitamiseks: automaatne ja k\u00e4sitsi. M\u00f5lemal juhul v\u00f5ivad s\u00f5numid t\u00f6\u00f6tlemiseks korduvalt l\u00e4bi k\u00e4ia, kui s\u00f5num on t\u00f6\u00f6deldud, kuid kinnitamine nurjus. Samuti saate s\u00f5numit \u00fcldse mitte t\u00f6\u00f6delda, kui kinnitamine toimus taustal ja teie kood l\u00f5petati enne, kui see t\u00f6\u00f6tlemisega alustas (v\u00f5ib-olla Kafkas versioonis 0.9 ja vanemates versioonides).<\/p>\n<p>Nihke kinnitamise protsessi k\u00e4sitsi juhtimine on v\u00f5imalik Kafkas kasutatavas API-s, seades parameetri <i>enable.auto.commit<\/i> false v\u00e4\u00e4rtuseks ja kutsudes selgelt v\u00e4lja \u00fche j\u00e4rgmistest meetoditest:<\/p>\n<pre><code class=\"java\">void commitSync();\nvoid commitAsync();<\/code><\/pre>\n<p>\nKui soovite s\u00f5numit t\u00f6\u00f6delda \u201ev\u00e4hemalt \u00fcks kord\u201c, peate kinnitama nihke k\u00e4epideme koha pealt <i>commitSync ()<\/i>, t\u00e4ites selle k\u00e4su kohe p\u00e4rast s\u00f5numite t\u00f6\u00f6tlemist.<\/p>\n<p>Need meetodid ei v\u00f5imalda s\u00f5numeid kinnitada (tunnustamine) enne nende t\u00f6\u00f6tlemist, kuid nad ei tee midagi, et v\u00e4ltida v\u00f5imalikke topelt t\u00f6\u00f6tlemisi, samas luues illusiooni tehingulisusest. Kafkas pole tehinguid. Kliendil puudub v\u00f5imalus teha j\u00e4rgmist:<\/p>\n<ul>\n<li>Automaatne eba\u00f5nnestunud s\u00f5numi tagasikerimine. Tarbijad peavad ise k\u00e4sitlema erandeid, mis tulenevad probleemsetest koormatest ja tagasiside katkestustest, kuna nad ei saa toetuda s\u00f5numite edastamise kordamisele vahendaja poolt.<\/li>\n<li>Saata s\u00f5numeid mitmesse teema \u00fches aatomaaroperatsioonis. Nagu me varsti n\u00e4eme, v\u00f5ib erinevate teemade ja parameetrite \u00fcle kontroll olla erinevates masinates Kafka klastris, mis ei koordineeri tehinguid saatmisel. Artikli kirjutamise ajaks on tehtud teatud t\u00f6\u00f6 selle v\u00f5imaldamiseks KIP-98 kaudu.<\/li>\n<li>Siduda \u00fche s\u00f5numi lugemine \u00fchest teemast teise s\u00f5numi saatmisega teise teema. J\u00e4llegi, Kafka arhitektuur s\u00f5ltub paljusid s\u00f5ltumatutest masinatest, mis t\u00f6\u00f6tavad nagu \u00fcks buss, ja ei tehta mingeid katseid seda peita. N\u00e4iteks ei eksisteeri API komponente, mis v\u00f5imaldaksid siduda <i>Tarbij <\/i>ja <i>Tootja <\/i>tehingus. JMS-is tagab selle objekt <i>Seanss<\/i>, millest luuakse <i>S\u00f5numi tootjad <\/i>ja <i>S\u00f5numi tarbijad<\/i>.<\/li>\n<\/ul>\n<p>\nKui me ei saa toetuda tehingutele, siis kuidas saame tagada semantika, mis on l\u00e4hedasem traditsiooniliste s\u00f5numivahetuss\u00fcsteemide pakutavale?<\/p>\n<p>Kui on oht, et tarbija nihke suurus v\u00f5ib suureneda enne, kui s\u00f5num on t\u00f6\u00f6deldud, n\u00e4iteks tarbija rike ajal, siis ei ole tarbijal mingit viisi teada saada, kas tema tarbijagrupp on s\u00f5numeid vahele j\u00e4tnud, kui talle m\u00e4\u00e4ratakse jaotus. Seet\u00f5ttu on \u00fcheks strateegiaks nihke tagasi keeramine eelmisele positsioonile. Kafka tarbija API pakub selleks j\u00e4rgmisi meetodeid:<\/p>\n<pre><code class=\"java\">void seek(TopicPartition partition, long offset);\nvoid seekToBeginning(Collection  partitions);<\/code><\/pre>\n<p>\nMeetod <i>seek ()<\/i> seda saab kasutada koos meetodiga <br \/>\n<i>offsetsForTimes (Map timestampsToSearch)<\/i> kui soovite minna tagasi mingisse kindlasse mineviku hetke.<\/p>\n<p>Implicitly, using this approach means that it is quite likely that some messages that were processed earlier will be read and processed again. To avoid this, we can use idempotent reading, as described in Chapter 4, to track previously viewed messages and exclude duplicates.<\/p>\n<p>Alternatively, your consumer code can be simple if message loss or duplication is acceptable. When we consider the use cases for which Kafka is typically used, such as log event processing, metrics, click tracking, etc., we understand that losing individual messages is unlikely to have a significant impact on surrounding applications. In such cases, default values are perfectly acceptable. On the other hand, if your application needs to process payments, you must take great care with each individual message. It all comes down to context.<\/p>\n<p>Isiklikud t\u00e4helepanekud n\u00e4itavad, et koos s\u00f5numite intensiivsuse kasvuega v\u00e4heneb iga eraldi s\u00f5numi v\u00e4\u00e4rtus. Suurehulga s\u00f5numid muutuvad tavaliselt v\u00e4\u00e4rtuslikuks, kui neid vaadelda koondatud kujul.<\/p>\n<h2>K\u00f5rge k\u00e4ttesaadavus (High Availability)<\/h2>\n<p>\nKafkastik k\u00f5rge k\u00e4ttesaadavuse l\u00e4henemine erineb oluliselt ActiveMQ l\u00e4henemisest. Kafka on v\u00e4lja t\u00f6\u00f6tatud horisontaalselt skaaleeritavate klastrite p\u00f5hjal, kus k\u00f5ik maakleri eksemplarid aktsepteerivad ja jagavad s\u00f5numeid samaaegselt.<\/p>\n<p>Kafka klaster koosneb mitmest maakleri eksemplarist, mis t\u00f6\u00f6tavad erinevates serverites. Kafka on projekteeritud t\u00f6\u00f6tama tavalisel iseseisval riistvaral, kus igal s\u00f5lmel on oma eraldatud andmem\u00e4lu. V\u00f5rgu kaudu talletatavate andmete (SAN) kasutamine ei ole soovitatav, kuna mitu arvutuslikku s\u00f5lme v\u00f5ivad konkureerida ajaintervallide p\u00e4rast ja tekitada konflikte.<i>A<\/i>li<\/p>\n<p>Kafka on <i>pidevalt sisse l\u00fclitatud<\/i> s\u00fcsteem. Paljud suured Kafka kasutajad ei sulge oma klastreid ning tarkvara tagab alati uuenduse j\u00e4rjestikku taask\u00e4ivitades. See saavutatakse, garanteerides \u00fchilduvuse varasema versiooniga s\u00f5numite ja vahetuste vahel brokerite.<\/p>\n<p>Brokerid on \u00fchendatud serverite klastriga <noindex><a rel=\"nofollow\" href=\"http:\/\/zookeeper.apache.org\">ZooKeeper<\/a><\/noindex>, mis toimib konfiguratsioonide registrina ja mida kasutatakse iga brokera rollide koordineerimiseks. ZooKeeper on ise jaotatud s\u00fcsteem, mis tagab k\u00f5rge saadavuse teabe replikatsiooni kaudu kvorumite loomisega. <i>kvorum<\/i>.<\/p>\n<p>Baastasemel luuakse teema Kafka klastris j\u00e4rgmiste omadustega:<\/p>\n<ul>\n<li>Partitsioonide arv. Nagu eelnevalt mainitud, s\u00f5ltub siin kasutatav t\u00e4pne v\u00e4\u00e4rtus soovitud paralleelse lugemise tasemest.<\/li>\n<li>Replikatsiooni koefitsient m\u00e4\u00e4rab, kui palju brokera eksemplare klastris peavad selle partitsiooni logisid sisaldama.<\/li>\n<\/ul>\n<p>\nKasutades ZooKeepers'i koordineerimiseks, p\u00fc\u00fcab Kafka \u00f5iglaselt jaotada uusi partitioone klastris olevate brokerite vahel. Seda teeb \u00fcks eksemplar, mis t\u00e4idab Kontrolleri rolli.<\/p>\n<p>k\u00e4itamisel <i>iga teema partitsiooni jaoks<\/i> <i>Kontroller <\/i>m\u00e4\u00e4ra brokerile rollid <i>juhi <\/i>(leader, master, juht) ja <i>j\u00e4rgijad <\/i>(followers, slaves, alamad). Broker, kes toimib juhi rollis antud partitsioonile, vastutab k\u00f5igi s\u00f5numite vastuv\u00f5tmise eest, mida produtsendid talle saadavad, ja s\u00f5numite levitamise eest tarbijatele. Kui s\u00f5numid saadetakse teema partitsiooni, kopeeritakse need k\u00f5ikidele brokeri s\u00f5lmedele, mis tegutseb selle partitsiooni j\u00e4rgijatena. Iga s\u00f5lm, millel on partitsiooni kuurnalud, nimetatakse <i>kopeerimiseks<\/i>. Broker v\u00f5ib olla juhi rollis m\u00f5nedele partitsioonidele ja j\u00e4rgija rollis teistele.<\/p>\n<p>J\u00e4rgija, kellel on k\u00f5ik s\u00f5numid, mis on juhi juures salvestatud, kutsutakse <i>s\u00fcnkroniseeritud kopeerimiseks<\/i> (s\u00fcnkroonse olekuga koopiaga, in-sync replica). Kui partitsiooni juhtiv broker v\u00e4ljub, v\u00f5ib iga broker, kellel on selle partitsiooni suhtes ajakohane v\u00f5i s\u00fcnkroonne olek, v\u00f5tta juhtrolli. See on uskumatult vastupidav disain.<\/p>\n<p>ProProduceri konfiguratsiooni osana on parameeter <i>acks<\/i>, mis m\u00e4\u00e4rab, kui palju koopiaid peab s\u00f5numi vastuv\u00f5tu kinnitama (acknowledge), enne kui rakenduse voog j\u00e4tkab saatmist: 0, 1 v\u00f5i k\u00f5ik. Kui v\u00e4\u00e4rtus on m\u00e4\u00e4ratud <i>all<\/i>, saadab juht s\u00f5numi saamisel kinnituse (confirmation) tagasi producerile, kui ta on saanud kinnituse (acknowledgements) mitmelt koopialt (sealhulgas endalt), mis on m\u00e4\u00e4ratud teema <i>min.insync.replicas<\/i> (vaikimisi 1). Kui s\u00f5numi edastamine ei \u00f5nnestu, kutsun producer rakenduses esile erandi (<i>NotEnoughReplicas<\/i> v\u00f5i <i>NotEnoughReplicasAfterAppend<\/i>).<\/p>\n<p>T\u00fc\u00fcpilises konfiguratsioonis luuakse teema kopeerimisteguri 3 (1 juht, 2 j\u00e4rgijat iga partitsiooni jaoks) ja parameetrit <i>min.insync.replicas<\/i> seadistatakse v\u00e4\u00e4rtuseks 2. Sellisel juhul lubab klaster, et \u00fcks teema partitsiooni haldav broker v\u00f5ib v\u00e4lja l\u00fclituda ilma, et see m\u00f5jutaks kliendi rakendusi.<\/p>\n<p>See viib meid tagasi juba tuttava kompromissi juurde tootlikkuse ja usaldusv\u00e4\u00e4rsuse vahel. Replikatsioon toimub t\u00e4iendava kinnitusajaga (acknowledgments) j\u00e4rgijatelt. Kuigi kuna see toimub paralleelselt, on replikatsioon, v\u00e4hemalt kolme s\u00f5lmega, sama tootlik nagu kahega (m\u00e4rkamata v\u00f5rgu ribalaiuse suurenemist).<\/p>\n<p>Kasutades seda replikatsiooni skeemi, v\u00e4ldib Kafka osavalt vajadust tagada iga s\u00f5numi f\u00fc\u00fcsiline salvestamine ketasse toimingu kaudu <i>sync ()<\/i>. Iga s\u00f5num, mille tootja saadab, salvestatakse partiilugejatesse, kuid nagu arutati peat\u00fckis 2, toimub algne salvestamine operatsioonis\u00fcsteemi puhverisse. Kui see s\u00f5num on replikatsioonitud teisele Kafka eksemplarile ja asub selle m\u00e4lus, ei t\u00e4henda liidri kaotus, et s\u00f5num ise on kadunud \u2014 selle v\u00f5ib enda peale v\u00f5tta s\u00fcnkroonitud replikatsioon.<br \/>\nOmandamisest loobumine operatsiooni t\u00e4itmise vajadusest <i>sync ()<\/i> t\u00e4hendab, et Kafka saab s\u00f5numeid vastu v\u00f5tta kiirusel, millega ta suudab neid m\u00e4llu kirjutada. Ja vastupidi, mida kauem saab v\u00e4ltida m\u00e4lu kirjutamist kettale, seda parem. Seet\u00f5ttu ei ole haruldane, et Kafka vahendajatele eraldatakse 64 GB m\u00e4lu v\u00f5i rohkem. Selline m\u00e4lu kasutamine t\u00e4hendab, et \u00fcks Kafka eksemplar suudab t\u00f6\u00f6tada kiirusel, mis on mitmeid tuhandeid kordi kiirem kui traditsiooniline s\u00f5numite vahendaja.<\/p>\n<p>Kafka saab ka seadistada operatsiooni rakendamiseks <i>sync ()<\/i> s\u00f5numipakettide juurde. Kuna k\u00f5ik Kafka puhul on suunatud pakettide t\u00f6\u00f6tlemisele, t\u00f6\u00f6tab see paljude kasutusjuhtumite puhul t\u00f5eliselt h\u00e4sti ja on kasulik t\u00f6\u00f6riist kasutajatele, kes n\u00f5uavad v\u00e4ga tugevaid garantiisid. Suurem osa Kafka puhtast j\u00f5udlusest on seotud s\u00f5numitega, mis saadetakse maaklerile pakettide kujul, ja nende s\u00f5numite lugemisega maaklerist j\u00e4rjestikeste plokkidena abil <noindex><a rel=\"nofollow\" href=\"http:\/\/www.linuxjournal.com\/article\/6345\">zero-copy<\/a><\/noindex> operatsioonide (operatsioonide, mille k\u00e4igus andmete kopeerimise \u00fclesanne ei toimu). Viimane on suur v\u00f5it j\u00f5udluse ja ressursside osas ning on v\u00f5imalik ainult t\u00e4nu aluseks olevale logistruktuurile, mis m\u00e4\u00e4ratleb partitsiooni skeemi.<\/p>\n<p>Kafka klaster pakub palju k\u00f5rgemat j\u00f5udlust kui \u00fcksik Kafka maakler, kuna teema partitsioonid v\u00f5ivad horisontaalselt skaleeruda paljudele eraldi masinatele.<\/p>\n<h2>Kokkuv\u00f5te<\/h2>\n<p>\nSelles peat\u00fckis k\u00e4sitlesime, kuidas Kafka arhitektuur \u00fcmber m\u00f5testab suhete loomist klientide ja vahendajate vahel, et tagada uskumatult usaldusv\u00e4\u00e4rne s\u00f5numivahetuse voog, mille l\u00e4bilaskev\u00f5ime on palju suurem kui tavalise s\u00f5numivahendaja oma. Arutasime funktsionaalsust, mida see selle eesm\u00e4rgi saavutamiseks kasutab, ja vaatasime \u00fcle rakenduste arhitektuuri, mis seda funktsionaalsust pakub. J\u00e4rgmises peat\u00fckis k\u00e4sitleme \u00fchistest probleemidest, millega s\u00f5numivahetusp\u00f5hised rakendused tegelevad, ja arutame nende lahendamise strateegiaid. L\u00f5petame peat\u00fcki, sketchides, kuidas m\u00f5elda s\u00f5numivahetustehnoloogiatele laiemalt, et saaksite hinnata nende sobivust teie kasutusjuhtumite jaoks.<\/p>\n<p>Eelmine t\u00f5lgitud osa: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">S\u00f5numite vahendajate m\u00f5istmine. S\u00f5numite vahetuse mehhanika uurimine ActiveMQ ja Kafka abil. Peat\u00fckk 1.<\/a><\/noindex><\/p>\n<p><b> T\u00f5lge on tehtud: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p><i>J\u00e4tkub\u2026<\/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\">Kas teie organisatsioonis kasutatakse Kafka't?<\/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>                    Kasutati varem, praegu mitte<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Plaanime kasutada<\/p>\n<\/li>\n<\/ul>\n<p>    H\u00e4\u00e4letas 38 kasutajat. 8 kasutajat j\u00e4id erapooletuks.<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 4.9.10 - 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 \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\" \/>\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) 4.9.10\" \/>\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 \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\" \/>\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\u00f5numite vahendajate m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 3. Kafka | ProHoster","description":"T\u00f5lke j\u00e4tkamine v\u00e4ikesest raamatust: \u201eUnderstanding Message Brokers\u201c, autor: Jakub Korab, v\u00e4ljaandja: O'Reilly Media, Inc., v\u00e4ljaandmise kuup\u00e4ev: juuni 2017, ISBN: 9781492049296. Eelmine t\u00f5lgitud osa: S\u00f5numite vahendajate m\u00f5istmine. S\u00f5numivahetuse mehhanika uurimine ActiveMQ ja Kafka kaudu. Peat\u00fckk 1. Sissejuhatus PEAT\u00dcKK 3 Kafka. Kafka on loodud LinkedInis, et \u00fcletada traditsiooniliste s\u00f5numite vahendajate teatud piiranguid ja","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 \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","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"},"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}]}}