Mitte ainult töötlemine: Kuidas me tegime Kafka Streams'ist jaotatud andmebaasi ja mis sellest välja tuli

Tere, Habr!

Tulet meelde, et koos raamatuga Kafka oleme välja andnud mitte vähem huvitava teose raamatukogust Kafka Streams API.

Kuni kogukond alles avastab selle võimsa tööriista võimalusi. Hiljuti ilmus artikkel, millega soovime teid tutvustada. Autor jagab oma kogemust, kuidas luua Kafka Streamsist hajutatud andmesalvestus. Head lugemist!

Apache'i raamatukogu Kafka Streams kasutatakse kogu maailmas ettevõtetes hajutatud voogude töötlemiseks Apache Kafka peal. Üks selle raamistikku alahinnatud aspekte on see, et see võimaldab salvestada kohaliku oleku, mis on toodetud voogude töötlemise alusel.

Selles artiklis räägin, kuidas õnnestus meil selle võimaluse kasulikult rakendada pilve rakenduste turvalisuse toote arendamisel. Kafka Streams'i abiga lõime mikroteenused, millel on jagatud olek, kus igaühes teenindatakse meid tõrke- ja kõrge kättesaadavuse allikana usaldusväärse teabe saamiseks objekti oleku kohta süsteemis. Meie jaoks on see samm edasi nii usaldusväärsuse kui ka hoolduse mugavuse osas.

Kui olete huvitatud alternatiivsest lähenemisest, mis võimaldab kasutada ühte kesksest andmebaasi objekti formaalse oleku toetamiseks – lugege edasi, see on huvitav…

Miks me leidsime, et on aeg muuta oma lähenemisviise jagatud oleku käsitlemisel

Meil oli vaja toetada erinevate objektide olekut, tuginedes agentide aruannetele (näiteks: kas veebileht oli rünnaku alla sattunud)? Enne üleminekut Kafka Streamsile toetusid me sageli oleku haldamisel ühele keskasandmebaasile (+ teenuse API). Sellel lähenemisel on oma puudused: andmedintensiivsetes olukordades talituse järjepidevuse ja sünkroniseerimise tagamine muutub tõeliseks väljakutseks. Andmebaas võib jõuda kitsaskohaks või sattuda võistlusolukorda ja kannatada ettearvamatuse all.

Illustratsioon 1: tüüpiline olukord, kus jagatud olek oli enne üleminekut
Kafka ja Kafka Streamsile: agendid edastavad oma arusaamad API kaudu, ajakohastatud olek arvutatakse keskse andmebaasi kaudu

Tutvustame Kafka Streamsi – nüüd on lihtne luua mikroteenuseid jagatud olekuga

Umbes aasta tagasi otsustasime põhjalikult üle vaadata oma jagatud oleku tööstsenaariumid, et mõista selliseid probleeme. Otsustasime kohe proovida Kafka Streams'i – on teada, kui skaleeritav, suure kättesaadavuse ja tõrke suhtes vastupidav see on, samuti kui rikkalik on selle voogedastuse funktsionaalsus (sealhulgas oleku säilitamisega transformatsioonid). Just seda vajasime, rääkimata, kui küps ja usaldusväärne on Kafka sõnumite vahetussüsteem.

Iga loodud oleku säilitamisega mikroteenus põhines päris lihtsa topoloogiaga Kafka Streams'i instantsil. See koosnes 1) allikast 2) protsessorist koos püsiva võtme-väärtuse salvestusega 3) voost:

Illustreerimine 2: vaikimisi topoloogia meie voogedastuse instantside jaoks mikroteenustes, kus on oleku säilitamine. Pane tähele: siin on ka salvestus, kus hoitakse andmeid planeerimise kohta.

Uue lähenemise kohaselt koostavad agentuurid sõnumid, mis saadetakse algsesse teemasse, ja tarbijad – näiteks meiliteenused – saavad arvutatud jagatud oleku voost (väljaanneteema) täielikult.

Joonis 3: uus ülesannete voog jagatud mikroteenuste stsenaariumi jaoks: 1) agent genereerib sõnumi, mille kaudu jõuab see Kafka algsesse teemasse; 2) jagatud olekuga mikroteenus (kasutades Kafka Streams'i) töötleb selle ja salvestab arvutatud oleku Kafka lõppteemasse; pärast seda 3) tarbijad saavad uue oleku.

Hei, see sisseehitatud võtmete ja väärtuste hoidja on tõeliselt kasulik!

Kuidas mainitud, sisaldab meie jagatud olekute topoloogia võtmete ja väärtuste hoidjat. Oleme leidnud mitmeid kasutusvõimalusi, millest kaks on allpool kirjeldatud.

Variant #1: võtmete ja väärtuste hoidja kasutamine arvutustes.

Meie esimene võtmete ja väärtuste hoidla sisaldas abiteavet, mis oli vajalik meie arvutuste jaoks. Näiteks mõningatel juhtudel määrati jagatud olek „enamuse häälte“ põhimõtte alusel. Hoidlas sai hoida kõiki viimaseid agente raportite kohta mingist objektist. Saades seejärel uue raporti ühelt või teiselt agentilt, saime selle salvestada, välja tõmmata hoidlast teiste agentide raportid sama objekti kohta ning uued arvutused korrata.
Allpool on näidatud, kuidas avasime pääsu võtmete ja väärtuste hoidla töötlevasse protsessori meetodisse, et seejärel saaks töödelda uut sõnumit.

Illustratsioon 4: avame pääsu võtmete ja väärtuste hoidla töötleva protsessori meetodi jaoks (pärast seda peab iga stsenaarium, mis töötab jagatud olekuga, implementima meetodi doProcess)

Variant #2: CRUD API loomine Kafka Streams'i kohal

Pärast meie põhijärjestuse loomist oleme proovinud kirjutada RESTful CRUD API meie jagatud olekuga mikroteenuste jaoks. Soovisime, et oleks võimalik välja tuua teatud või kõigi objektide olek ning samuti seada või eemaldada objekti olekut (see on kasulik serveri toe pakkumisel).

Selleks, et toetada kõiki API Get State, igal korral, kui oli vaja uuesti arvutada olekut töötlemise käigus, salvestasime selle pikaks ajaks sisseehitatud võtme-väärtuse salvestusse. Sellisel juhul on piisavalt lihtne rakendada sellist API ühe Kafka Streams eksemplariga, nagu on näidatud allpool olevas loendis.

Illustratsioon 5: sisseehitatud võtme-väärtuse salvestuse kasutamine objekti eelarvutatava oleku saamiseks.

Objekti oleku värskendamine API kaudu on samuti lihtsalt rakendatav. Põhimõtteliselt on sellega vaid vajalik luua Kafka tootja ja selle abil teha kirje, milles on uus olek. Nii tagatakse, et kõik API kaudu genereeritud sõnumid töödeldakse täpselt samamoodi nagu muude tootjate (nt agentide) poolt saadetud sõnumid.

Illustreerimine 6: objekti olek muutub kasutades Kafka produtsenti

Väike komplikatsioon: Kafka-l on palju partiisid

Soovisime koormust, mis oli seotud töötlemisega, jaotada ning kättesaadavust parandada, pakkudes igale stsenaariumile klastrit mikroteenuseid jagatud olekuga. Seade sujus meil lihtsasti: pärast seda, kui konfigureerisime kõik instantsid töötama sama rakenduse ID-ga (ja samade alglaadimise serveritega), tehti praktiliselt kõik muu automaatselt. Me määrasime ka, et iga lähteteema koosneb mitmest partiist, et igale instantsile saaks määrata partii alamkogumi.

Mainin ka, et siin on tavaline teha olekute hoiukoha varukoopia, et näiteks tõrke korral saaks selle koopia teisele instantsile üle kanda. Iga oleku hoiukoha jaoks Kafka Streams'is luuakse replikatsioonitopik muudatuste logiga (kus jälgitakse kohalikke värskendusi). Seega tagab Kafka pidevalt oleku hoiukoha turvalisuse. Seetõttu saab oleku hoiukohta kiiresti taastada teisel instantsil, kuhu vastavad partiid üleviivad. Meie testid näitasid, et see toimub mõne sekundi jooksul, isegi kui hoiukohta on salvestatud miljoneid kirjeid.

Üleminek ühe jagatud olekuga mikroteenuselt klastrile mikroteenuseid muudab Get State API rakendamise vähem triviaalseks. Uues olukorras sisaldab iga mikroteenuse olekute salvestuses ainult osa tervikpildist (need objektid, mille võtmed vastavad konkreetsele partitsioonile). Pidi välja selgitama, millises instantsis vajalik objekti olek asub, ja tegime seda voogude metaandmete alusel, nagu on näidatud allpool:

Illustratsioon 7: voogude metaandmete abil määrame, milliselt instantsilt küsida vajaliku objekti olekut; sarnast lähenemist rakendati ka GET ALL API puhul.

Peamised järeldused

Kafka Striimis olevad olekute salvestused võivad de facto toimida jaotatud andmebaasina,

• mis on pidevalt replitseeritav Kafka-s.
• Selle süsteemi peal on lihtne üles ehitada CRUD API.
• Mitme partitsiooni töötlemine osutub veidi keerulisemaks.
• Samuti on võimalik lisada üks või mitu olekute salvestust voogude topoloogiasse, et salvestada abiteavet. Sellist varianti võib kasutada:
• Pikaajalise andmete salvestamiseks, mida vajatakse voogude töötlemise arvutustes.
• Pikaandmeid, mis võivad olla kasulikud järgmise voogedastuse instantsi algseadmistes.
• palju muud…

Nende ja teiste eeliste tõttu sobib Kafka Streams suurepäraselt globaalse oleku toetamiseks sellises jaotatud süsteemis nagu meie. Kafka Streams on osutunud väga usaldusväärseks tootmisjärgus (alates selle juurutamisest pole me praktiliselt kaotanud sõnumeid), ja me oleme kindlad, et sellevõimalused ei piirdu sellega!

Allikas: habr.com