Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

Aupa Habr!

Gogorarazten dizuegu buruz liburua jarraituz Kafka liburutegiari buruzko lan berdin interesgarri bat argitaratu dugu Kafka Streams APIa.

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

Oraingoz, komunitatea tresna indartsu honen mugak ikasten ari da. Beraz, duela gutxi artikulu bat argitaratu zen, zeinaren itzulpena aurkeztu nahi dizuegu. Bere esperientziatik, egileak Kafka Streams datu-biltegiratze banatu batean nola bihurtu kontatzen du. Gozatu irakurtzen!

Apache liburutegia Kafka errekak Apache Kafkaren gainean banatutako korronteen prozesatzeko enpresetan mundu osoan erabiltzen da. Esparru honen gutxiesten den alderdietako bat haria prozesatzen oinarrituta ekoiztutako tokiko egoera gordetzeko aukera ematen duela da.

Artikulu honetan, esango dizut nola lortu zuen gure enpresak aukera hau errentagarri erabiltzea hodeiko aplikazioen segurtasunerako produktu bat garatzerakoan. Kafka Streams erabiliz, partekatutako egoera-mikrozerbitzuak sortu ditugu, eta horietako bakoitzak akatsekiko tolerantzia eta eskuragarritasun handiko informazio iturri gisa balio du sistemako objektuen egoerari buruz. Guretzat, hau aurrerapauso bat da bai fidagarritasunari eta bai laguntzaren erraztasunari dagokionez.

Zure objektuen egoera formala onartzen duen datu-base zentral bakarra erabiltzeko aukera ematen duen ikuspegi alternatibo bat interesatzen bazaizu, irakurri ezazu, interesgarria izango da...

Zergatik pentsatu genuen egoera partekatuarekin lan egiteko modua aldatzeko garaia zela

Agenteen txostenetan oinarrituta hainbat objekturen egoera mantendu behar genuen (adibidez: erasoa jasan al zen gunea)? Kafka Streams-era migratu aurretik, sarritan datu-base zentral bakar batean oinarritzen ginen (+ zerbitzu APIa) egoera kudeatzeko. Ikuspegi honek bere eragozpenak ditu: data intentsiboko egoerak koherentzia eta sinkronizazioa mantentzea benetako erronka bihurtzen da. Datu-basea botila-lepo bihur daiteke edo bertan bukatzea lasterketa-egoera eta ezustekoa jasaten.

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

1. Irudia: Trantsizio aurretik ikusitako zati-egoera ohikoa
Kafka eta Kafka korronteak: agenteek beren ikuspuntuak API bidez komunikatzen dituzte, egoera eguneratua datu-base zentral baten bidez kalkulatzen da.

Ezagutu Kafka Streams, egoera partekatuko mikrozerbitzuak sortzea erraztuz

Duela urtebete inguru, gure egoera partekatuko agertokiei gogor aztertzea erabaki genuen arazo horiei aurre egiteko. Berehala erabaki genuen Kafka Streams probatzea: badakigu zeinen eskalagarria, oso eskuragarria eta akatsekiko tolerantzia den, zer funtzionalitate aberatsa duen (eraldaketak, egoerakoak barne). Behar genuena, Kafkan mezularitza sistema zein heldua eta fidagarria bihurtu den ahaztu gabe.

Sortu ditugun egoera-mikrozerbitzu bakoitza Kafka Streams instantzia baten gainean eraiki zen, nahiko topologia sinple batekin. 1) iturburu bat 2) gako-balioen biltegi iraunkorra zuen prozesadore bat 3) konketa bat zen:

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

2. Irudia: gure streaming-instantziaren topologia lehenetsia egoera-mikrozerbitzuetarako. Kontuan izan plangintzako metadatuak dituen biltegi bat ere badagoela hemen.

Ikuspegi berri honetan, agenteek iturburuko gaian sartzen diren mezuak osatzen dituzte, eta kontsumitzaileek —esaterako, posta bidezko jakinarazpen-zerbitzu bat— konputatutako egoera partekatua jasotzen dute konketa bidez (irteerako gaia).

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

3. Irudia: Mikrozerbitzu partekatuak dituen eszenatoki baterako ataza-fluxu adibide berria: 1) agenteak Kafka iturburu-gaira iristen den mezu bat sortzen du; 2) egoera partekatua duen mikrozerbitzu batek (Kafka Streams erabiliz) prozesatzen du eta kalkulatutako egoera idazten du azken Kafka gaian; ondoren 3) kontsumitzaileek egoera berria onartzen dute

Aizu, oso erabilgarria da gako-balioen denda integratua!

Goian esan bezala, gure partekatutako egoera topologiak gako-balioen biltegia dauka. Erabiltzeko hainbat aukera aurkitu ditugu, eta horietako bi jarraian azaltzen dira.

1. aukera: erabili gako-balioen biltegia kalkuluak egiteko

Gure lehen gako-balioen biltegiak kalkuluetarako behar genituen datu osagarriak zituen. Esaterako, kasu batzuetan partekatutako egoera "gehiengo botoen" printzipioaren arabera zehazten zen. Biltegiak objektu batzuen egoerari buruzko azken agenteen txosten guztiak eduki ditzake. Gero, agente baten edo besteren txosten berri bat jaso genuenean, gorde genezake, beste agente guztien txostenak biltegiratzetik objektu beraren egoerari buruzkoak berreskuratu eta kalkulua errepikatu genezake.
Beheko 4. irudiak erakusten du gako/balioen biltegia prozesadorearen prozesatze-metodoari nola azaldu genion, gero mezu berria prozesatu ahal izateko.

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

4. irudia: prozesadorearen prozesatzeko metodorako gako-balioen biltegirako sarbidea irekitzen dugu (ondoren, egoera partekatuarekin lan egiten duen script bakoitzak metodoa inplementatu behar du. doProcess)

2. aukera: CRUD API bat sortzea Kafka Streams-en gainean

Gure oinarrizko zeregin-fluxua ezarrita, gure egoera partekatuko mikrozerbitzuetarako RESTful CRUD API bat idazten saiatzen hasi ginen. Objektu batzuen edo guztien egoera berreskuratu ahal izan nahi genuen, baita objektu baten egoera ezarri edo kendu ere (backend laguntzarako erabilgarria).

Get State API guztiak onartzeko, prozesatzeko garaian egoera berriro kalkulatu behar genuen bakoitzean, gako-balioen biltegi batean gorde genuen denbora luzez. Kasu honetan, nahiko erraza da API bat ezartzea Kafka Streams-en instantzia bakarra erabiliz, beheko zerrendan erakusten den moduan:

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

5. Irudia: Eraikitako gako-balioen biltegia erabiltzea objektu baten aurrez kalkulatutako egoera lortzeko

Objektu baten egoera APIaren bidez eguneratzea ere erraza da inplementatzen. Funtsean, Kafka ekoizle bat sortu eta egoera berria duen disko bat egiteko erabiltzea besterik ez da egin behar. Horrek bermatzen du APIaren bidez sortutako mezu guztiak beste ekoizleengandik (adibidez, agenteak) jasotzen dituzten modu berean prozesatuko direla.

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

6. Irudia: Kafka ekoizlea erabiliz objektu baten egoera ezar dezakezu

Konplikazio txikia: Kafkak partizio asko ditu

Ondoren, prozesatzeko karga banatu eta erabilgarritasuna hobetu nahi izan dugu egoera bakoitzeko egoera partekatuko mikrozerbitzu multzo bat eskainiz. Konfigurazioa oso erraza izan zen: behin instantzia guztiak aplikazioaren ID berdinarekin (eta bootstrap zerbitzari berdinekin) exekutatzeko konfiguratu genituenean, ia gainerako guztia automatikoki egin zen. Iturburu-gai bakoitza hainbat partizioz osatuta egongo zela ere zehaztu genuen, instantzia bakoitzari partizio horien azpimultzo bat esleitu ahal izateko.

Gainera, aipatuko dut praktika arrunta dela estatuko dendaren babeskopia bat egitea, adibidez, hutsegite baten ondoren berreskuratzen bada, kopia hau beste instantzia batera transferitzeko. Kafka Streams-en egoera-denda bakoitzeko, erreplikatutako gai bat sortzen da aldaketa-erregistro batekin (tokiko eguneratzeen jarraipena egiten duena). Horrela, Kafkak etengabe egiten du babeskopia estatuko denda. Hori dela eta, Kafka Streams-en instantzia baten edo besteren hutsegiteen kasuan, egoera-biltegia azkar berrezarri daiteke beste instantzia batean, dagozkion partizioak joango diren tokian. Gure probek erakutsi dute hori segundo gutxitan egiten dela, nahiz eta dendan milioika disko egon.

Partekatutako egoera duen mikrozerbitzu bakar batetik mikrozerbitzu multzo batera igaroz, ez da hain hutsala bihurtu Get State APIa ezartzea. Egoera berrian, mikrozerbitzu bakoitzaren egoera biltegiak irudi orokorraren zati bat baino ez dauka (gakoak partizio zehatz batera mapatu zituzten objektuak). Behar genuen objektuaren egoera zein instantzia zuen zehaztu behar genuen, eta hariaren metadatuetan oinarrituta egin genuen, behean erakusten den moduan:

Ez prozesatzea bakarrik: Kafka Streams-etik banatutako datu-base bat nola egin genuen eta zer atera zen

7. Irudia: Korrontearen metadatuak erabiliz, nahi den objektuaren egoera zein instantzitatik kontsultatu behar den zehazten dugu; antzeko hurbilketa bat erabili zen GET ALL APIarekin

Funtsezko aurkikuntzak

Kafka Streams-en estatuko dendak de facto banatutako datu-base gisa balio dezakete.

  • etengabe errepikatzen da Kafkan
  • CRUD API bat erraz eraiki daiteke sistema horren gainean
  • Hainbat partizio kudeatzea apur bat zailagoa da
  • Gainera, posible da egoera-biltegi bat edo gehiago gehitzea streaming topologiara datu laguntzaileak gordetzeko. Aukera hau erabil daiteke:
  • Korronteen prozesatzean kalkuluak egiteko beharrezkoak diren datuak epe luzerako biltegiratzea
  • Streaming instantzia hornitzen den hurrengo aldian erabilgarriak izan daitezkeen datuen epe luzerako biltegiratzea
  • askoz gehiago...

Abantaila hauek eta beste batzuk Kafka Streams oso egokia da gurea bezalako sistema banatu batean egoera globala mantentzeko. Kafka Streams-ek ekoizpenean oso fidagarria dela frogatu du (inplementatu genuenetik ez dugu ia mezu galerarik izan), eta ziur gaude bere gaitasunak ez direla hor geldituko!

Iturria: www.habr.com

Gehitu iruzkin berria