Liburu txiki baten itzulpenaren jarraipena:
Mezu-artekariak ulertzea
egilea: Jakub Korab, argitaletxea: O'Reilly Media, Inc., argitalpen data: 2017ko ekaina, ISBN: 9781492049296.
Itzulitako aurreko zatia:
3. KAPITULUA
Kafka
Kafka LinkedIn-ek garatu zuen ohiko mezuen artekarien muga batzuk gainditzeko eta puntuz puntuko interakzio desberdinetarako hainbat mezu-artekari konfiguratu beharrik ez izateko, liburu honetan deskribatzen dena 28. orrialdean "Eskalatzea eta handitzea" atalean. Erabilera kasuak LinkedIn neurri handi batean datu kopuru handien ingesta modu bakarrean oinarritu da, hala nola orrialdeen klikak eta sarbide-erregistroak, eta, hala ere, datu horiek hainbat sistemak erabiltzeko aukera ematen du ekoizleen edo beste kontsumitzaileen produktibitatean eragin gabe. Izan ere, Kafka existitzearen arrazoia Universal Data Pipeline-k deskribatzen duen mezularitza-arkitektura lortzea da.
Azken helburu hori ikusita, beste eskakizun batzuk sortu ziren berez. Kafkak behar luke:
- Izan oso azkarra
- Eman banda zabalera gehiago mezuekin lan egiten duzunean
- Argitaletxe-Harpidedun eta Puntu-puntu ereduak onartzen ditu
- Ez moteldu kontsumitzaileak gehitzearekin. Esaterako, ActiveMQ-n ilararen eta gaiaren errendimendua hondatzen da helmugan kontsumitzaile kopurua hazi ahala.
- Horizontalki eskalagarria izan; Mezuak mantentzen dituen artekari batek diskoaren abiadura maximoan soilik egin dezakeen arren, zentzuzkoa da broker instantzia bakar batetik haratago joatea errendimendua areagotzeko.
- Mugatu mezuak gordetzeko eta berriro berreskuratzeko sarbidea
Hori guztia lortzeko, Kafkak bezeroen eta mezularitza-artekarien rolak eta erantzukizunak birdefinitzen zituen arkitektura bat hartu zuen. JMS eredua oso broker orientatuta dago, non artekaria mezuak banatzeaz arduratzen den eta bezeroek mezuak bidaltzeaz eta jasotzeaz bakarrik arduratu behar duten. Kafka, berriz, bezeroarengan oinarritzen da, bezeroak ohiko broker baten ezaugarri asko hartzen dituelarik, esate baterako, kontsumitzaileentzako mezu garrantzitsuak justu banatzea, bitartekari oso azkar eta eskalagarri baten truke. Mezularitza-sistema tradizionalekin lan egin duten pertsonentzat, Kafkarekin lan egiteak funtsezko iritzi-aldaketa eskatzen du.
Ingeniaritza-norabide honek mezularitza-azpiegitura bat sortzea ekarri du, ohiko broker batekin alderatuta, abiadura handitzeko gai dena. Ikusiko dugunez, ikuspegi honek truke-offekin dator, hau da, Kafka ez da egokia lan-karga eta instalatutako software mota batzuetarako.
Helmuga Eredu bateratua
Goian deskribatutako baldintzak betetzeko, Kafkak argitalpen-harpidetza eta puntuz puntuko mezularitza bateratu ditu helmuga mota batean - Gai. Hau nahasgarria da mezularitza-sistemekin lan egin duten pertsonentzat, non "gai" hitzak difusio-mekanismo bati egiten dio erreferentzia, non (gaitik) irakurketa iraunkorra ez den. Kafka gaiak helmuga mota hibridotzat hartu behar dira, liburu honen sarreran definitu bezala.
Kapitulu honen gainerakoan, esplizituki kontrakoa adierazten ez badugu behintzat, "gai" terminoak Kafka gai bati erreferentzia egingo dio.
Gaiek nola jokatzen duten eta zer berme ematen duten ondo ulertzeko, lehenik eta behin Kafkan nola ezartzen diren aztertu behar dugu.
Kafkan gai bakoitzak bere erregistroa du.
Kafkari mezuak bidaltzen dizkioten ekoizleek erregistro honetan idazten dute, eta kontsumitzaileek erregistrotik irakurtzen dute etengabe aurrera doazen erakusleak erabiliz. Aldian-aldian, Kafkak erregistroaren zati zaharrenak ezabatzen ditu, zati horietako mezuak irakurriak izan ala ez. Kafkaren diseinuaren zati nagusia da brokerari ez diola axola mezuak irakurtzen diren edo ez; hori bezeroaren ardura da.
"Erregistroa" eta "erakuslea" terminoak ez dira agertzen . Termino ezagun hauek ulertzen laguntzeko erabiltzen dira hemen.
Eredu hau ActiveMQ-tik guztiz ezberdina da, non ilara guztietako mezuak erregistro berean gordetzen diren eta bitartekariak mezuak ezabatuta bezala markatzen ditu irakurri ondoren.
Goazen orain pixka bat sakondu eta aztertu gaiaren erregistroa xehetasun gehiagorekin.
Kafka erregistroa hainbat partizioz osatuta dago (). Kafkak ordena zorrotza bermatzen du partizio bakoitzean. Horrek esan nahi du ordena jakin batean partizioan idatzitako mezuak ordena berean irakurriko direla. Partizio bakoitza duen erregistro-fitxategi gisa inplementatzen da azpimultzo bat bere ekoizleek gaiari bidalitako mezu guztien (azpimultzoa). Sortutako gaiak, lehenespenez, partizio bat dauka. Partizioen ideia Kafkaren ideia nagusia da eskalatze horizontalerako.
3-1 irudia. Kafka Partizioak
Ekoizle batek Kafka gai bati mezu bat bidaltzen dionean, mezua zein partiziotara bidali erabakitzen du. Geroago aztertuko dugu zehatzago.
Mezuak irakurtzea
Mezuak irakurri nahi dituen bezeroak deitutako erakuslea kudeatzen du kontsumo taldea, seinalatzen duena desplazamendu mezuak partizioan. Desplazamendu bat partizio baten hasieran 0-n hasten den posizio inkrementala da. Erabiltzaileak definitutako group_id bidez erreferentziatutako APIan kontsumitzaile talde honi dagokio kontsumitzaile edo sistema logiko bat.
Mezularitza-sistema gehienek helmugako datuak irakurtzen dituzte hainbat instantzia eta hari erabiliz mezuak paraleloan prozesatzeko. Horrela, normalean kontsumo-talde bera partekatzen duten kontsumitzaile-instantzia asko egongo dira.
Irakurketaren arazoa honela irudikatu daiteke:
- Gaiak hainbat partizio ditu
- Kontsumitzaile talde anitzek gai bat erabil dezakete aldi berean
- Kontsumitzaile talde batek hainbat instantzia bereizi izan ditzake
Hau asko-to-asko arazo ez hutsala da. Kafkak kontsumitzaile-taldeen, kontsumo-instantziaren eta partizioen arteko harremanak nola kudeatzen dituen ulertzeko, ikus ditzagun irakurketa agertoki konplexuagoak pixkanaka.
Kontsumitzaileak eta kontsumo taldeak
Har dezagun abiapuntu gisa partizio bakarreko gai bat ().
3-2 irudia. Kontsumitzaileak partiziotik irakurtzen du
Kontsumitzaile-instantzia bat gai honi bere group_id-arekin konektatzen denean, irakurketa-partizioa eta desplazamendu bat esleitzen zaizkio partizio horretan. Desplazamendu honen posizioa bezeroan konfigura daiteke posizio berriena (mezu berriena) edo posizio zaharrena (mezu zaharrena) erakusle gisa. Kontsumitzaileak gaiaren mezuak (inkestak) eskatzen ditu, eta horrek erregistrotik irakurketa sekuentziala dakar.
Desplazamenduaren posizioa aldizka Kafka-ra itzultzen da eta barneko gai batean mezu gisa gordetzen da _kontsumitzaile_konpentsazioak. Irakurritako mezuak oraindik ez dira ezabatzen, ohiko broker batek ez bezala, eta bezeroak desplazamendua atzera egin dezake dagoeneko ikusitako mezuak berriro prozesatzeko.
Bigarren kontsumitzaile logiko bat talde_id ezberdin bat erabiliz konektatzen denean, lehenengoaren independentea den bigarren erakuslea kudeatzen du (). Horrela, Kafka gai batek kontsumitzaile bat dagoen ilara baten antzera jokatzen du eta kontsumitzaile anitz harpidetzen diren argitaratze-harpidetza (pub-sub) gai arrunt baten antzera, mezu guztiak gordetzeko eta hainbat aldiz prozesatu daitezkeen abantaila gehigarriarekin.
3-3 irudia. Kontsumitzaile talde ezberdinetako bi kontsumitzailek partizio beretik irakurtzen dute
Kontsumo talde bateko kontsumitzaileak
Kontsumitzaile-instantzia batek partizio bateko datuak irakurtzen dituenean, erakuslearen kontrol osoa du eta mezuak prozesatzen ditu aurreko atalean azaldu bezala.
Kontsumitzaileen hainbat instantzia talde_id berdinarekin partizio bakarreko gai bati konektatzen bazaizkio, orduan konektatu zen azken instantziari erakuslearen kontrola emango zaio eta une horretatik aurrera mezu guztiak jasoko ditu ().
3-4 irudia. Kontsumitzaile talde bereko bi kontsumitzailek partizio beretik irakurtzen dute
Kontsumitzaile-instantzia kopurua partizio-kopurua gainditzen duen prozesatzeko modu hau kontsumitzaile esklusibo moduko bat dela pentsa daiteke. Hau erabilgarria izan daiteke zure kontsumitzaile-instantziaren "aktibo-pasibo" (edo "bero-bero") multzokatzea behar baduzu, nahiz eta hainbat kontsumitzaile paraleloan exekutatu ("aktibo-aktibo" edo "bero-bero") baino askoz ere ohikoagoa den. kontsumitzaileak.Egonean.
Goian deskribatutako mezuen banaketa-jokabide hau harrigarria izan daiteke JMS ilara arrunt batek nola jokatzen duenarekin alderatuta. Eredu honetan, ilara bidaltzen diren mezuak bi kontsumitzaileen artean banatuko dira.
Gehienetan, kontsumitzaileen instantzia anitz sortzen ditugunean, mezuak paraleloan prozesatzeko edo irakurtzeko abiadura handitzeko edo irakurketa-prozesuaren egonkortasuna areagotzeko egiten dugu. Kontsumitzaileen instantzia bakarrak partizio bateko datuak aldi berean irakur ditzakeenez, nola lortzen da hori Kafkan?
Horretarako modu bat kontsumitzaileen instantzia bakarra erabiltzea da mezu guztiak irakurtzeko eta hari multzora pasatzeko. Ikuspegi honek prozesatzeko errendimendua handitzen duen arren, kontsumitzaileen logikaren konplexutasuna areagotzen du eta ez du ezer egiten irakurketa sistemaren sendotasuna handitzeko. Kontsumitzailearen kopia bat jaisten bada elektrizitate hutsegite bat edo antzeko gertaera baten ondorioz, kenketa gelditzen da.
Kafkan arazo hau konpontzeko modu kanonikoa b erabiltzea daΠpartizio gehiago.
Banaketa
Partizioak dira bitartekari instantzia bakar baten banda-zabaleratik harago gai bat irakurtzeko eta eskalatzeko mekanismo nagusia. Hau hobeto ulertzeko, kontuan har dezagun bi partizio dituen gai bat dagoen eta kontsumitzaile bat gai honetara harpidetzen den egoera bat ().
3-5 irudia. Kontsumitzaile batek partizio anitzetatik irakurtzen du
Eszenatoki honetan, kontsumitzaileari bere group_id-ari dagozkion erakusleen gaineko kontrola ematen zaio bi partizioetan eta bi partizioetako mezuak irakurtzen hasten da.
Gai honi talde_id bererako kontsumitzaile gehigarri bat gehitzen zaionean, Kafkak partizioetako bat lehengo kontsumitzailetik bigarrenera birlokatzen du. Horren ondoren, kontsumitzailearen instantzia bakoitzak gaiaren partizio batetik irakurriko du ().
Mezuak 20 haritan paraleloan prozesatzen direla ziurtatzeko, gutxienez 20 partizio behar dituzu. Partizio gutxiago badaude, lan egiteko ezer ez duten kontsumitzaileekin geratuko zara, kontsumitzaile esklusiboen eztabaidan lehen azaldu bezala.
3-6 irudia. Kontsumo talde bereko bi kontsumitzailek partizio ezberdinetatik irakurtzen dute
Eskema honek asko murrizten du Kafka brokeraren konplexutasuna JMS ilara mantentzeko beharrezkoa den mezu banaketarekin alderatuta. Hemen ez duzu honako puntu hauetaz kezkatu behar:
- Zein kontsumitzailek jaso beharko luke hurrengo mezua, round-robin esleipenean, aurrez jasotzeko bufferen egungo ahalmenean edo aurreko mezuetan (JMS mezu-taldeetan bezala).
- Zein mezu bidaltzen diren zein kontsumitzaileri eta ea berriro entregatu behar diren hutsegite kasuan.
Kafka artekariak egin behar duen guztia kontsumitzaileari mezuak sekuentzialki pasatzea da, azken honek eskatzen dituenean.
Hala ere, huts egindako mezuak zuzentzeko eta berriro bidaltzeko eskakizunak ez dira desagertzen - horien erantzukizuna brokerarengandik bezeroarengana pasatzen da. Horrek esan nahi du zure kodean kontuan hartu behar direla.
Mezuak bidaltzea
Mezu horren ekoizlearen ardura da mezua zein partiziotara bidali erabakitzea. Hau egiten den mekanismoa ulertzeko, lehenik eta behin benetan zer bidaltzen ari garen kontuan hartu behar dugu.
JMS-n metadatuekin (goiburuak eta propietateak) eta karga (karga karga) duen gorputz bat erabiltzen dugun bitartean, Kafkan mezua da. "gako-balioa" bikotea. Mezuaren karga balio gisa bidaltzen da. Gakoa, berriz, zatiketa egiteko erabiltzen da batez ere eta eduki behar du negozio-logikako gako espezifikoaerlazionatutako mezuak partizio berean jartzeko.
2. kapituluan, erlazionatutako gertaerak kontsumitzaile bakar batek ordenan prozesatu behar dituen lineako apustuen eszenatokia aztertu dugu:
- Erabiltzaile kontua konfiguratuta dago.
- Dirua kontuan sartzen da.
- Kontutik dirua ateratzen duen apustua egiten da.
Gertaera bakoitza gai bati argitaratutako mezua bada, orduan gako naturala kontuaren IDa izango litzateke.
Mezu bat Kafka Producer APIa erabiliz bidaltzen denean, partizio-funtzio batera pasatzen da eta horrek, mezua eta Kafka klusterraren uneko egoera kontuan hartuta, mezua bidali behar den partizioaren IDa itzultzen du. Ezaugarri hau Javan inplementatzen da Partitioner interfazearen bidez.
Interfaze honek itxura hau du:
interface Partitioner {
int partition(String topic,
Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}Partitioner inplementazioak helburu orokorreko hashing algoritmo lehenetsia erabiltzen du gakoaren gainean partizioa zehazteko, edo round-robin gakorik ez bada zehazten. Balio lehenetsi honek ondo funtzionatzen du kasu gehienetan. Hala ere, etorkizunean zurea idatzi nahi izango duzu.
Zure partizio-estrategia idaztea
Ikus dezagun adibide bat non metadatuak bidali nahi dituzun mezuen kargarekin batera. Gure adibideko karga jokoaren kontuan gordailua egiteko instrukzioa da. Instrukzio bat transmisioan aldatuko ez dela bermatu nahiko genukeen zerbait da eta ziurtatu nahi dugu upstream konfiantzazko sistema batek soilik abiarazi dezakeela instrukzio hori. Kasu honetan, igorle- eta jasotzaile-sistemek sinaduraren erabilera adosten dute mezua autentifikatzeko.
JMS arruntean, "mezuaren sinadura" propietate bat definitzen dugu eta mezuari gehitzen diogu. Hala ere, Kafkak ez digu metadatuak pasatzeko mekanismorik eskaintzen, gako bat eta balio bat baizik.
Balioa osotasuna gorde nahi dugun banku-transferentzia karga bat denez, ez dugu gakoan erabili beharreko datu-egitura definitzea beste aukerarik. Partiziorako kontu ID bat behar dugula suposatuz, kontu batekin erlazionatutako mezu guztiak ordenan prozesatu behar direnez, JSON egitura hau sortuko dugu:
{
"signature": "541661622185851c248b41bf0cea7ad0",
"accountId": "10007865234"
}Sinaduraren balioa kargaren arabera aldatuko denez, Partitioner interfazearen hashing estrategia lehenetsiak ez ditu fidagarritasunez taldekatuko erlazionatutako mezuak. Hori dela eta, gako hau analizatu eta accountId balioa zatituko duen estrategia propioa idatzi beharko dugu.
Kafkak dendan dauden mezuen ustelkeria detektatzeko checksumak biltzen ditu eta segurtasun-eginbide multzo osoa du. Hala eta guztiz ere, batzuetan, industriaren eskakizun espezifikoak, goikoa esaterako, agertzen dira.
Erabiltzailearen partizio-estrategiak erlazionatutako mezu guztiak partizio berean amaitzen direla ziurtatu behar du. Honek sinplea dirudien arren, baldintza konplexua izan daiteke erlazionatutako mezuak ordenatzearen garrantziagatik eta gai bateko partizio kopurua zenbateraino finkoa den.
Gai bateko partizio kopurua denboran zehar alda daiteke, trafikoa hasierako itxaropenak gainditzen baditu gehi daitezkeelako. Horrela, mezu-gakoak jatorriz bidali ziren partizioarekin lotu daitezke, ekoizle-instantziaren artean partekatu beharreko egoera-zati bat esan nahi du.
Kontuan hartu beharreko beste faktore bat mezuen banaketa uniformea ββda partizioetan. Normalean, gakoak ez dira modu berdinean banatzen mezuetan, eta hash funtzioek ez dute bermatzen mezuen banaketa zuzena gako multzo txiki baterako.
Garrantzitsua da kontuan izan mezuak zatitzea aukeratzen duzun edozein dela ere, baliteke bereizlea bera berrerabili behar izatea.
Kontuan izan kokapen geografiko ezberdinetan Kafka klusterren artean datuak errepikatzeko eskakizuna. Horretarako, MirrorMaker izeneko komando lerroko tresna batekin dator Kafkak, zeina kluster batetik mezuak irakurtzeko eta beste batera transferitzeko erabiltzen dena.
MirrorMaker-ek erreplikatutako gaiaren gakoak ulertu behar ditu mezuen arteko ordena erlatiboa mantentzeko klusterren artean erreplikatzean, baliteke gai horren partizio-kopurua ez izatea berdina bi multzotan.
Partizio pertsonalizatuen estrategiak nahiko arraroak dira, hashing edo round robin lehenetsiak ondo funtzionatzen baitu agertoki gehienetan. Hala ere, ordenatzeko berme sendoak behar badituzu edo karga-kargaetatik metadatuak atera behar badituzu, orduan partizioa sakonago aztertu beharko zenuke.
Kafkaren eskalagarritasun eta errendimendu onurak broker tradizionalaren ardura batzuk bezeroarengana aldatzean datoz. Kasu honetan, paraleloan lan egiten duten hainbat kontsumitzaileren artean erlazionatutako mezuak banatzeko erabakia hartzen da.
JMS artekariek ere eskakizun horiei aurre egin behar diete. Interesgarria da kontsumitzaile berari erlazionatutako mezuak bidaltzeko mekanismoak, JMS Mezu Taldeen bidez inplementatuta (SLB) estrategiaren aldaera, igorleak mezuak erlazionatutako gisa markatzea eskatzen du. JMS-ren kasuan, bitartekaria arduratzen da erlazionatutako mezuen talde hau kontsumitzaile askoren bati bidaltzeaz eta taldearen jabetza transferitzeaz kontsumitzailea erortzen bada.
Ekoizleen Hitzarmenak
Partizioa ez da mezuak bidaltzerakoan kontuan hartu beharreko gauza bakarra. Ikus ditzagun Producer klaseko send() metodoak Java APIan:
Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);Berehala esan behar da bi metodoek Etorkizuna itzultzen dutela, eta horrek adierazten du bidalketa eragiketa ez dela berehala egiten. Ondorioz, mezu bat (ProducerRecord) bidalketa-buferrean idazten da partizio aktibo bakoitzeko eta Kafka bezeroaren liburutegian atzeko hari gisa brokerra bidaltzen da. Horrek gauzak izugarri bizkortzen dituen arren, esan nahi du esperientziarik gabeko aplikazio batek mezuak gal ditzakeela bere prozesua gelditzen bada.
Beti bezala, bidalketa eragiketa fidagarriagoa egiteko modu bat dago errendimenduaren kontura. Buffer honen tamaina 0-n ezar daiteke, eta bidaltzen duen aplikazio-haria bitartekariari mezu-transferentzia amaitu arte itxaron behar izango da, honela:
RecordMetadata metadata = producer.send(record).get();Mezuak irakurtzeari buruz gehiago
Mezuak irakurtzeak espekulatu beharreko konplexutasun gehigarriak ditu. JMS APIa ez bezala, mezu baten entzule bat exekutatu dezake mezu bati erantzuteko Kontsumo- Kafkak soilik inkestak egiten ditu. Ikus dezagun metodoa hurbilagotik inkesta()horretarako erabiltzen da:
ConsumerRecords < K, V > poll(long timeout);Metodoaren itzulera-balioa hainbat objektu dituen edukiontzi-egitura da kontsumitzaileen erregistroa potentzialki hainbat partiziotik. kontsumitzaileen erregistroa bera da gako-balio-bikote baten edukitzaile-objektua da lotutako metadatuak dituena, hala nola eratorritako partizioa.
2. kapituluan aztertu bezala, kontuan izan behar dugu zer gertatzen den mezuekin arrakastaz edo arrakastaz prozesatu ondoren, adibidez, bezeroak ezin badu mezua prozesatu edo bertan behera uzten badu. JMS-n, hau aitorpen modu baten bidez kudeatzen zen. Agenteak behar bezala prozesatutako mezua ezabatuko du, edo mezu gordina edo faltsua berriro entregatuko du (transakzioak erabili zirela suposatuz).
Kafkak oso ezberdin funtzionatzen du. Mezuak ez dira brokeran ezabatzen zuzenketa egin ondoren, eta hutsegitean gertatzen dena zuzenketa-kodearen ardura da.
Esan dugunez, kontsumitzaile taldea erregistroko offsetarekin lotzen da. Desplazamendu honekin lotutako erregistro-posizioa erantzun gisa igorri beharreko hurrengo mezuari dagokio inkesta(). Desplazamendu hori handitzen den unea erabakigarria da irakurtzeko.
Lehen aipatu dugun irakurketa eredura itzuliz, mezuen prozesamenduak hiru fase ditu:
- Irakurtzeko mezu bat berreskuratu.
- Mezua prozesatu.
- Berretsi mezua.
Kafka kontsumitzaileak konfigurazio aukera batekin dator gaitu.auto.konpromisoa. Hau maiz erabiltzen den ezarpen lehenetsia da, "auto" hitza duten ezarpenekin ohikoa den bezala.
Kafka 0.10 baino lehen, aukera hau erabiltzen duen bezero batek hurrengo deian irakurritako azken mezuaren desplazamendua bidaliko zuen inkesta() prozesatu ondoren. Horrek esan nahi zuen lehendik eskuratutako mezuak berriro prozesatu ahal izango zirela, baldin eta bezeroak dagoeneko prozesatu bazituen baina ustekabean dei egin aurretik suntsitu bazen. inkesta(). Agenteak mezu bat zenbat aldiz irakurri den inongo egoera gordetzen ez duenez, mezu hori berreskuratzen duen hurrengo kontsumitzaileak ez du jakingo ezer txarrik gertatu den. Jokabide hori sasi-transakzionala zen. Desplazamendua mezua behar bezala prozesatu bazen bakarrik konprometitu zen, baina bezeroak bertan behera uzten bazuen, bitartekariak mezu bera bidaliko zuen berriro beste bezero bati. Jokaera hau koherentea zen mezuak bidaltzeko bermearekin "behin bederen".
Kafka 0.10-n, bezeroaren kodea aldatu egin da, bezeroen liburutegiak aldian-aldian konpromisoa abiarazteko, konfiguratutako moduan. auto.commit.interval.ms. Jokabide hau JMS AUTO_ACKNOWLEDGE eta DUPS_OK_ACKNOWLEDGE moduen artean dago. Autocommit erabiltzean, mezuak konprometitu daitezke benetan prozesatu diren ala ez kontuan hartu gabe; hori gerta liteke kontsumitzaile motel baten kasuan. Kontsumitzaile batek abortatzen badu, hurrengo kontsumitzaileak jasoko lituzke mezuak, konprometitutako posiziotik hasita, eta horrek galdutako mezu bat eragin dezake. Kasu honetan, Kafkak ez zituen mezuak galdu, irakurketa-kodeak ez zituen prozesatu.
Modu honek 0.9 bertsioko promesa bera du: mezuak prozesatu daitezke, baina huts egiten badu, baliteke desplazamendua ez konprometitzea, eta baliteke bidalketa bikoiztea eraginez. Zenbat eta mezu gehiago lortu exekutatzen duzunean inkesta(), orduan eta gehiago arazo hau.
21. orrialdean "Mezuak ilara batetik irakurtzea" atalean aipatzen den bezala, ez dago mezu bat behin-behineko bidalketa bezalako gauzarik mezularitza-sisteman hutsegite moduak kontuan hartzen direnean.
Kafkan, desplazamendu bat (konpromisoa) konprometitzeko (konpromisatzeko) bi modu daude: automatikoki eta eskuz. Bi kasuetan, mezuak hainbat aldiz prozesatu daitezke mezua prozesatu baina huts egin bada konpromisoa baino lehen. Mezua batere ez prozesatzea ere aukeratu dezakezu konpromezua atzeko planoan gertatu bada eta zure kodea prozesatu aurretik osatuta badago (agian Kafka 0.9 eta aurrekoetan).
Eskuzko konpentsazio prozesua kontrola dezakezu Kafka consumer APIan parametroa ezarriz gaitu.auto.konpromisoa metodo hauetako bat faltsu eta esplizituki deitzea:
void commitSync();
void commitAsync();Mezua "gutxienez behin" prozesatu nahi baduzu, desplazamendua eskuz egin behar duzu commitSync()komando hau mezuak prozesatu eta berehala exekutatuz.
Metodo hauek ez dute onartzen mezuak prozesatu aurretik aitortzea, baina ez dute ezer egiten prozesatzeko balizko atzerapenak kentzeko transakzio itxura ematen duten bitartean. Kafkan ez dago transakziorik. Bezeroak ez du honako hau egiteko gaitasunik:
- Atzera automatikoki faltsututako mezu bat. Kontsumitzaileek beraiek kudeatu behar dituzte karga arazotsuek eta backend-aren etenek eragindako salbuespenak, ezin baitute brokerengan fidatu mezuak berriro bidaltzeko.
- Bidali mezuak hainbat gairi eragiketa atomiko batean. Laster ikusiko dugunez, gai eta partizio ezberdinen kontrola bidalitakoan transakzioak koordinatzen ez dituzten Kafka klusterreko makina ezberdinetan egon daiteke. Hau idazteko momentuan, lan batzuk egin dira hori posible egiteko KIP-98rekin.
- Lotu gai bateko mezu bat irakurtzea beste mezu bat beste gai batera bidaltzearekin. Berriz ere, Kafkaren arkitektura makina independente askoren menpe dago autobus bakar gisa dabiltzan eta ez da hori ezkutatzeko ahaleginik egiten. Adibidez, ez dago lotzeko aukera emango dizun API osagairik kontsumitzailea ΠΈ Ekoizle transakzio batean. JMSn, hori objektuak ematen du Sessionbertatik sortzen dira Mezu-ekoizleak ΠΈ MezuaConsumers.
Transakzioetan fidatu ezin bagara, nola eman semantika mezularitza-sistema tradizionalek eskaintzen dutenetatik hurbilago?
Kontsumitzailearen desplazamendua mezua prozesatu baino lehen handitzeko aukera badago, kontsumitzaileen hutsegite batean adibidez, kontsumitzaileak ez du jakin nahi bere kontsumitzaile-taldeak mezua galdu duen ala ez partizio bat esleitzen zaionean. Beraz, estrategia bat desplazamendua aurreko posiziora itzultzea da. Kafka consumer APIak metodo hauek eskaintzen ditu horretarako:
void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);
ΠΠ΅ΡΠΎΠ΄ bilatu() metodoarekin erabil daiteke
offsetsForTimes(Mapa timestampsToSearch) iraganeko une zehatz batean egoera batera itzultzeko.
Inplizituki, ikuspegi hau erabiltzeak esan nahi du oso litekeena dela aurretik prozesatu ziren mezu batzuk irakurri eta berriro prozesatzea. Hori ekiditeko, irakurketa idempotentea erabil dezakegu, 4. kapituluan deskribatzen den moduan, aurrez ikusitako mezuen jarraipena egiteko eta bikoiztuak ezabatzeko.
Bestela, zure kontsumo-kodea sinplea izan daiteke, betiere mezua galtzea edo bikoiztea onargarria bada. Kafka erabili ohi den erabilera kasuak aztertzen ditugunean, esate baterako, erregistro-gertaerak, neurketak, kliken jarraipena eta abar kudeatzea, konturatzen gara mezu indibidualak galtzeak nekez izango duela eragin handirik inguruko aplikazioetan. Kasu horietan, balio lehenetsiak nahiko onargarriak dira. Bestalde, zure aplikazioak ordainketak bidali behar baditu, arreta handiz zaindu behar duzu mezu bakoitza. Dena testuingurura dator.
Behaketa pertsonalek erakusten dute mezuen intentsitatea handitzen den heinean mezu bakoitzaren balioa gutxitzen dela. Mezu handiak baliotsuak izan ohi dira forma agregatuan ikusten direnean.
Eskuragarritasun Handia
Kafkaren erabilgarritasun handiko ikuspegia ActiveMQren ikuspegitik oso desberdina da. Kafka kluster eskalagarrien inguruan diseinatu da, non broker-instantzia guztiek mezuak jasotzen eta banatzen dituzte aldi berean.
Kafka kluster batek zerbitzari ezberdinetan exekutatzen diren agente-instantzia anitzek osatzen dute. Kafka hardware autonomo arruntean exekutatzeko diseinatu zen, non nodo bakoitzak bere biltegiratze dedikatua duen. Ez da gomendatzen sarean atxikitako biltegiratzea (SAN) erabiltzea, hainbat konputazio-nodo denboran lehiatu daitezkeelako.Π«e biltegiratzeko tarteak eta gatazkak sortu.
Kafka da beti piztuta sistema. Kafkaren erabiltzaile handi askok ez dituzte inoiz klusterrak itzaltzen eta softwarea beti eguneratzen da berrabiarazi sekuentzial batekin. Mezuetarako eta artekarien arteko interakzioetarako aurreko bertsioarekin bateragarritasuna bermatuz lortzen da.
Zerbitzari-kluster batera konektatutako artekariak , konfigurazio-datuen erregistro gisa jokatzen duena eta bitartekari bakoitzaren rolak koordinatzeko erabiltzen dena. ZooKeeper bera sistema banatua da, eta eskuragarritasun handia eskaintzen du informazioaren erreplikaren bidez ezarriz quoruma.
Oinarrizko kasuan, gai bat sortzen da ezaugarri hauek dituen Kafka kluster batean:
- Partizio kopurua. Lehenago esan bezala, hemen erabiltzen den balio zehatza irakurketa paraleloaren nahi den mailaren araberakoa da.
- Erreplikazio-faktoreak (faktoreak) klusterreko broker-instantzia zenbatek partizio honetarako erregistroak izan behar dituzten zehazten du.
Koordinaziorako ZooKeepers erabiliz, Kafkak klusterreko artekarien artean partizio berriak zuzen banatzen saiatzen da. Kontrolatzaile gisa jarduten duen instantzia bakar batek egiten du.
Exekuzioan gai-zatiketa bakoitzerako Controller esleitu rolak broker bati liderra (burua, maisua, aurkezlea) eta jarraitzaileak (jarraitzaileak, esklaboak, menpekoak). Artekaria, partizio honen lider gisa, ekoizleek bidalitako mezu guztiak jasotzeaz eta kontsumitzaileei mezuak banatzeaz arduratzen da. Mezuak gai-partizio batera bidaltzen direnean, partizio horren jarraitzaile gisa jarduten duten bitartekari-nodo guztietan errepikatzen dira. Partizio baten erregistroak dituen nodo bakoitzari deitzen zaio erreplika. Agente batek partizio batzuetarako lider gisa eta besteentzat jarraitzaile gisa jardun dezake.
Liderrak dituen mezu guztiak dituen jarraitzaile bati deitzen zaio erreplika sinkronizatua (egoera sinkronizatuan dagoen erreplika, sinkronizatutako erreplika). Partizio baten lider gisa jarduten duen bitartekari batek behera egiten badu, partizio horretarako eguneratuta edo sinkronizatuta dagoen artekari batek har dezake lider rola. Diseinu izugarri iraunkorra da.
Ekoizlearen konfigurazioaren zati bat parametroa da akak, zeinak zehazten du zenbat erreplik izan behar duten mezu bat jaso (aitortu) aplikazioaren haria bidaltzen jarraitu aurretik: 0, 1 edo guztiak. ezartzen bada guztiak, gero, mezu bat jasotzen denean, liderrak berrespena bidaliko dio ekoizleari, gaiaren ezarpenak definitutako hainbat seinaleren (bere barne) diskoaren baieztapenak (onarpenak) jaso bezain laster. min.insync.erreplikak (lehenetsia 1). Mezua behar bezala errepikatu ezin bada, ekoizleak aplikazioaren salbuespen bat botako du (Not EnoughReplicas edo Not EnoughReplicasAfterAppend).
Konfigurazio tipiko batek 3ko erreplikazio-faktorea duen gai bat sortzen du (lider 1, 2 jarraitzaile partizio bakoitzeko) eta parametroarekin min.insync.erreplikak 2-an ezartzen da. Kasu honetan, klusterrak gaiaren partizioa kudeatzen duen bitartekarietako bati jaisten utziko dio bezeroen aplikazioei eragin gabe.
Honek errendimenduaren eta fidagarritasunaren arteko elkarlanera itzultzen gaitu. Erreplikatzea jarraitzaileen baieztapenak (onarpenak) itxaron denbora gehigarriaren kontura gertatzen da. Nahiz eta, paraleloan exekutatzen denez, gutxienez hiru nodotan erreplikatzeak biren errendimendu bera du (sare-banda-zabaleraren erabilera areagotzeari jaramonik egin gabe).
Erreplikazio-eskema hau erabiliz, Kafkak modu adimentsuan saihesten du eragiketarekin mezu bakoitza diskoan fisikoki idazteko beharra. sinkronizatu(). Ekoizleak bidalitako mezu bakoitza partizioen erregistroan idatziko da, baina 2. kapituluan azaldu bezala, fitxategi batean idaztea sistema eragilearen bufferean egiten da hasieran. Mezu hau Kafkaren beste instantzia batean errepikatzen bada eta bere memorian badago, liderra galtzeak ez du esan nahi mezua bera galdu zenik; sinkronizatutako erreplika batek har dezake.
Eragiketa egiteari uko egitea sinkronizatu() esan nahi du Kafkak mezuak memorian idazten dituen bezain azkar jaso ditzakeela. Aitzitik, zenbat eta denbora gehiago saihestu memoria diskora hustu, orduan eta hobeto. Hori dela eta, ez da arraroa Kafka artekariek 64 GB edo gehiago memoria esleitzea. Memoria-erabilera honek esan nahi du Kafka instantzia bakar bat mezu-artekari tradizionalak baino milaka aldiz azkarrago exekutatu daitekeela erraz.
Kafka ere konfigura daiteke eragiketa aplikatzeko sinkronizatu() mezu paketeetara. Kafka-n dena paketeetara bideratuta dagoenez, benetan nahiko ondo funtzionatzen du erabilera kasu askotan eta tresna erabilgarria da oso berme sendoak behar dituzten erabiltzaileentzat. Kafkaren errendimendu hutsaren zati handi bat brokerari pakete gisa bidaltzen zaizkion mezuetatik dator eta mezu hauek brokertik bloke sekuentzialetan irakurtzen direla. eragiketak (memoria eremu batetik bestera datuak kopiatzeko zeregina egiten ez den eragiketak). Azken hau errendimendu eta baliabide irabazi handia da eta partizio-eskema definitzen duen azpiko erregistro-datuen egitura baten bidez soilik posible da.
Kafka kluster batean errendimendu askoz hobea da Kafka broker bakarrarekin baino, gai-partizioak makina ezberdin askotan eskala daitezkeelako.
Emaitzak
Kapitulu honetan, Kafka arkitekturak bezeroen eta bitartekarien arteko harremana nola berriro irudikatzen duen aztertu dugu, mezularitza-bideo oso sendoa eskaintzeko, ohiko mezu-artekari batena baino askoz ere handiagoa izan dadin. Hori lortzeko erabiltzen dituen funtzionaltasunaz eztabaidatu dugu eta funtzionalitate hori ematen duten aplikazioen arkitekturari erreparatu diogu labur. Hurrengo kapituluan, mezularitzan oinarritutako aplikazioek horiei aurre egiteko estrategiak konpontzeko eta eztabaidatzeko behar dituzten ohiko arazoak aztertuko ditugu. Kapitulua mezularitza-teknologiei buruz orokorrean nola hitz egin azalduz amaituko dugu, zure erabilera kasuetarako egokiak diren ebalua dezazun.
Itzulitako aurreko zatia:
Itzulpena egina:
Jarraitu ahal izateko ...
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Kafka erabiltzen al da zure erakundean?
-
Bai
-
No
-
Lehen erabiltzen zen, orain ez
-
Erabiltzeko asmoa dugu
38 erabiltzailek eman dute botoa. 8 erabiltzaile abstenitu ziren.
Iturria: www.habr.com