Mitte ainult töötlemine: Kuidas me muutsime Kafka Streams jaotatud andmebaasiks ja mis sellest välja tuli

Tere, Habr!

Tuletame 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. Nii ilmus hiljuti artikkel, millega tahame teid tutvustada. Autor jagab oma kogemusi, kuidas luua Kafka Streamsist jaotatud andmehoidla. Head lugemist!

Apache raamatukogu Kafka Streams kasutatakse üle terve maailma ettevõtetes jaotatud voogude töötlemiseks Apache Kafka peal. Üks selle raamistikku alahinnatud aspekte on see, et see võimaldab hoida kohalikku olekut, mis on loodud voogude töötlemise põhjal.

Selles artiklis räägin, kuidas suutsime oma ettevõttes seda võimalust kasulikult rakendada, arendades pilve rakenduste turvalisuse tooteid. Kafka Streams'i abil lõime mikroteenuseid, millel on jagatud olek, millest igaühel on meie jaoks tõrkedeta ja kõrgelt kergesti saadaval teabeallikas süsteemis olevate objektide oleku kohta. Meie jaoks on see edasiminek nii usaldusväärsuse kui ka hoolduse mugavuse osas.

Kui teid huvitab alternatiivne lähenemine, mis võimaldab kasutada ühtset keskvabasid andmebaasi teie objektide formaalse oleku toetamiseks – lugege, see on huvitav...

Miks me arvasime, et on aeg oma lähenemist jagatud olekuga muuta

Meil oli vaja toetada erinevate objektide olekute haldamist, toetudes agentide aruannetele (näiteks: kas saidi vastu tehti rünnak?). Enne Kafka Streamsile üleminekut tuginesime sageli oleku haldamiseks ühele kesksule andmebaasile (+ teenuste API). Selle lähenemise miinused on: kuivaine intensiivsetes olukordades ühtsuse ja sünkroniseerimise tagamine muutub tõeliseks väljakutseks. Andmebaas võib muutuda kitsaskohaks või sattuda võistluseseisundisse ja kannatada ettearvamatuse all.

Illustratsioon 1: tüüpiline stsenaarium jagatud olekuga, mis esines enne üleminekut
Kafka ja Kafka Streamsile: agentide aruanded edastatakse API kaudu, uuendatud olek arvutatakse keskses andmebaasis

Tutvuge Kafka Streams'iga – nüüd on lihtne luua mikroteenuseid jagatud olekuga

Umbes aasta tagasi otsustasime tõsiselt üle vaadata meie tööskeemid jagatud olekuga, et tegeleda selliste probleemidega. Otsustasime kohe proovida Kafka Streams'i – on teada, kui skaleeritav, kõrge kättesaadavuse ja tõrketaluv süsteem see on ning kui rikkalik on selle voogude funktsionaalsus (kaasa arvatud, oleku salvestamise võimalused). Just seda me vajasime, rääkimata sellest, kui küps ja usaldusväärne on sõnumite vahetamise süsteem Kafka-s.

Iga meie loodud oleku salvestamise mikroteenus ehitati soovitud Kafka Streams'i instantsi baasil, millel oli üsna lihtne topoloogia. See koosnes 1) allikast 2) töötlejast, millel on pidev võtmete ja väärtuste salvestus 3) väljundist:

Illustratsioon 2: meie voogude instantside vaikimisi topoloogia oleku salvestamise mikroteenuste jaoks. Pange tähele: siin on ka salvestus, kus on säilitatud planeerimise metaandmed.

Uue lähenemise korral koostavad agentuurid sõnumeid, mis edastatakse algsesse teema, ja tarbijad – ütleme, et postituseteenuse teenus – vastu võtavad arvutatud jagatud oleku väljundi (väljunditeema) kaudu.

Illustratsioon 3: uus ülesandev voog jagatud mikroteenuste stsenaariumi jaoks: 1) agent loob sõnumi, mis saadetakse Kafka algsesse teema; 2) jagatud oleku mikroteenus (kasutades Kafka Streams'i) töötleb seda ja salvestab arvutatud oleku Kafka lõppteemasse; seejärel 3) tarbijad võtavad uue oleku vastu.

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

Nagu eespool mainitud, sisaldab meie jagatud olekuga topoloogia võtmete ja väärtuste salvestust. Oleme leidnud mitu võimalust selle kasutamiseks, ja kaks neist on allpool kirjeldatud.

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

Meie esimene võtmete ja väärtuste hoidla sisaldas abiteavet, mida vajasime arvutamiseks. Näiteks määrati mõnel juhul jagatud olek „enamushääletuse“ printsiibi järgi. Hoidlas sai hoida kõiki viimaseid agentide aruandeid teatud objekti oleku kohta. Seejärel, kui saime uue aruande mõnelt agentidelt, saime salvestada selle, tõmmata hoidlast välja kõikide teiste agentide aruanded sama objekti oleku kohta ja arvutamist korrata.
Allpool, joonisel 4, on näidatud, kuidas avasime juurdepääsu võtmete ja väärtuste hoidla pro tervendava meetodi jaoks, et hiljem oleks võimalik uut sõnumit töödelda.

Joonis 4: avame juurdepääsu võtmete ja väärtuste hoidla pro tervendava meetodi jaoks (pärast seda tuleb igas stsenaariumis, mis töötab jagatud olekuga, rakendada meetodit doProcess)

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

Pärast meie baatsooside voo seadistamist hakkasime proovima kirjutada RESTful CRUD API meie jagatud olekuga mikroteenustele. Soovisime, et oleks võimalik saada teatud või kõikide objektide olekut ning seadistada või eemaldada objekti olek (see on kasulik serveripoolse toe säilitamiseks).

Kuna kõikide API Get State toetamiseks, kui meil oli vaja olekut uuesti arvutada töötlemise käigus, salvestasime selle pikaks ajaks sisseehitatud võtmete ja väärtuste hoidlasse. Sel juhul on piisav lihtsalt sellise API rakendamine ühe Kafka Streams'i eksemplari abil, nagu on näidatud allolevas loendis:

Joonis 5: sisseehitatud võtmete ja väärtuste hoidla kasutamine objekti eelnevalt arvutatud oleku saamiseks

Objekti oleku uuendamine API kaudu ei ole samuti keeruline. Põhimõtteliselt peab selle jaoks lihtsalt looma Kafka producer'i ja selle abil tegema kirje, milles on uus olek. Nii tagatakse, et kõik API kaudu genereeritud sõnumid töödeldakse täpselt samamoodi nagu teised producentide (nt agendid) kaudu saadetud sõnumid.

Joonis 6: objekti olekut saab seadistada Kafka produceri abil

Väike keerukus: Kafka'l on palju partitsioone

Seejärel tahtsime jaotada töötluse koormust ja parandada kättesaadavust, luues igale stsenaariumile klastrise mikroteenuste süsteemi, millel on jagatud olek. Seadistamine oli meie jaoks lihtne: pärast seda, kui konfigureerisime kõik instantsid töötama sama rakenduse ID-ga (ja samade alglaadimise serveritega), tehti praktiliselt kõik muu automaatselt. Samuti seadsime me, et iga sisenditeema koosneb mitmest partiisist, et igale instantsile saaks määrata partii alamhulga.

Tahan mainida ka, et siin on tavaks teha olekuhoidla varukoopia, et näiteks tõrke taastamisel see koopia teisele instantsile viia. Iga olekuhoidla jaoks Kafka Streamsis luuakse kopeeritav teema muudatuste logiga (kus jälgitakse kohalikku värskendust). Nii tagab Kafka pidevalt olekuhoidla kaitse. Seega, kui mõne instantsi Kafka Streamsis esineb tõrge, saab olekuhoidla kiiresti taastada teisel instantsil, kuhu liiguvad sobivad partiid. Meie testid näitasid, et see toimub mõne sekundi jooksul isegi siis, kui olekus on miljoneid kirjeid.

Minna ühest jagatud olekuga mikroteenusest mikroteenuste klastrisse, ei ole Get State API rakendamine enam nii triviaalne. Uues olukorras sisaldab iga mikroteenuse olekuhoidla ainult osa kogu pildist (need objektid, mille võtmed seondusid konkreetsele partiile). Pidi määrama, millises instantsis oli vajalik objekti olek, ja tegime seda voogude metaandmete alusel, nagu on allpool näidatud:

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

Peamised järeldused

Olekuhoidlad Kafka Streamsis võivad de facto toimida jaotatud andmebaasina,

• mida kopeeritakse pidevalt Kafka
• Sellise süsteemi peale on lihtne luua CRUD API
• Mitme partii töötlemine osutub veidi keerulisemaks
• Samuti on võimalik lisada voogedastustopoloogiasse üks või mitu olekuhoidlat abiteabe salvestamiseks. Seda varianti saab kasutada:
• Pikaajaline andmete salvestamine, mis on vajalik voogedastuse töötlemisel arvutuste jaoks
• Pikaajaline andmete salvestamine, mis võib olla kasulik järgmise voogedastuse instantsi initsialiseerimisel
• paljude teiste jaoks...

Nende ja teiste eeliste tõttu sobib Kafka Streams suurepäraselt globaalse oleku toetamiseks sellises jaotatud süsteemis nagu meie. Kafka Streams on tootmiskeskkonnas osutunud väga usaldusväärseks (alates selle juurutamisest pole me praktiliselt ühtegi sõnumit kaotanud) ja oleme kindlad, et sellega ei piirdub tema võimekus!

Allikas: habr.com