Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

Čau Habr!

Atgādinām, ka sekojot grāmatai par Kafka esam publicējuÅ”i tikpat interesantu darbu par bibliotēku Kafka Streams API.

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

Pagaidām sabiedrÄ«ba tikai apgÅ«st Ŕī spēcÄ«gā rÄ«ka robežas. Tātad, nesen tika publicēts raksts, ar kura tulkojumu mēs vēlamies jÅ«s iepazÄ«stināt. No savas pieredzes autors stāsta, kā Kafka Streams pārvērst par izkliedētu datu krātuvi. Izbaudi lasÄ«Å”anu!

Apache bibliotēka Kafkas straumes izmanto visā pasaulē uzņēmumos izplatÄ«tai straumju apstrādei papildus Apache Kafka. Viens no Ŕīs sistēmas nenovērtētajiem aspektiem ir tas, ka tas ļauj uzglabāt vietējās valsts ražotās, pamatojoties uz pavedienu apstrādi.

Å ajā rakstā pastāstÄ«Å”u, kā mÅ«su uzņēmumam izdevās izdevÄ«gi izmantot Å”o iespēju, izstrādājot produktu mākoņa aplikāciju droŔībai. Izmantojot Kafka Streams, mēs izveidojām koplietojamus stāvokļa mikropakalpojumus, no kuriem katrs kalpo kā kļūdu izturÄ«gs un ļoti pieejams uzticamas informācijas avots par sistēmas objektu stāvokli. Mums tas ir solis uz priekÅ”u gan uzticamÄ«bas, gan atbalsta viegluma ziņā.

Ja jūs interesē alternatīva pieeja, kas ļauj izmantot vienu centrālo datu bāzi, lai atbalstītu jūsu objektu formālo stāvokli, izlasiet to, tas būs interesanti...

Kāpēc mēs domājām, ka ir pienācis laiks mainīt veidu, kā mēs strādājam ar kopīgu stāvokli

Mums bija jāuztur dažādu objektu stāvoklis, pamatojoties uz aÄ£entu ziņojumiem (piemēram: vai vietne tika uzbrukta)? Pirms migrÄ“Å”anas uz Kafka Streams mēs bieži paļāvāmies uz vienu centrālo datu bāzi (+ pakalpojuma API) valsts pārvaldÄ«bai. Å ai pieejai ir savi trÅ«kumi: randiņu intensÄ«vas situācijas konsekvences un sinhronizācijas saglabāŔana kļūst par Ä«stu izaicinājumu. Datubāze var kļūt par vājo vietu vai nonākt tajā sacensÄ«bu stāvoklis un cieÅ” no neparedzamÄ«bas.

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

1. attēls. Tipisks sadalītā stāvokļa scenārijs, kas redzams pirms pārejas uz
Kafka un Kafka Streams: aģenti paziņo savus uzskatus, izmantojot API, atjauninātais stāvoklis tiek aprēķināts, izmantojot centrālo datu bāzi

Iepazīstieties ar Kafka Streams, kas atvieglo koplietojamo valsts mikropakalpojumu izveidi

Apmēram pirms gada mēs nolēmām rÅ«pÄ«gi izskatÄ«t mÅ«su kopÄ«gos stāvokļa scenārijus, lai risinātu Ŕīs problēmas. Mēs nekavējoties nolēmām izmēģināt Kafka Streams ā€” mēs zinām, cik tas ir mērogojams, ļoti pieejams un izturÄ«gs pret kļūmēm, kāda ir bagātÄ«ga straumÄ“Å”anas funkcionalitāte (pārveidojumi, ieskaitot statusu). TieÅ”i tas, kas mums bija vajadzÄ«gs, nemaz nerunājot par to, cik nobriedusi un uzticama ir kļuvusi Kafkas ziņojumapmaiņas sistēma.

Katrs mÅ«su izveidotais status mikropakalpojums tika izveidots, izmantojot Kafka Streams gadÄ«jumu ar diezgan vienkārÅ”u topoloÄ£iju. Tas sastāvēja no 1) avota 2) procesora ar pastāvÄ«gu atslēgu vērtÄ«bu krātuvi 3) izlietnes:

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

2. attēls. MÅ«su straumÄ“Å”anas gadÄ«jumu noklusējuma topoloÄ£ija statusu saturoÅ”iem mikropakalpojumiem. Ņemiet vērā, ka Å”eit ir arÄ« repozitorijs, kurā ir plānoÅ”anas metadati.

Šajā jaunajā pieejā aģenti veido ziņojumus, kas tiek ievadīti avota tēmā, un patērētāji, piemēram, pasta paziņojumu pakalpojums, saņem aprēķināto koplietoto stāvokli caur izlietni (izvades tēmu).

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

3. attēls. Jauns uzdevuma plūsmas piemērs scenārijam ar koplietotiem mikropakalpojumiem: 1) aģents ģenerē ziņojumu, kas nonāk Kafkas avota tēmā; 2) mikropakalpojums ar koplietojamo stāvokli (izmantojot Kafka Streams) to apstrādā un ieraksta aprēķināto stāvokli galīgajā Kafkas tēmā; pēc kura 3) patērētāji pieņem jauno stāvokli

Hei, Å”is iebÅ«vētais atslēgu vērtÄ«bu veikals patiesÄ«bā ir ļoti noderÄ«gs!

Kā minēts iepriekÅ”, mÅ«su koplietojamā stāvokļa topoloÄ£ija satur atslēgu vērtÄ«bu krātuvi. Mēs atradām vairākas tā izmantoÅ”anas iespējas, un divas no tām ir aprakstÄ«tas tālāk.

1. iespēja: aprēķiniem izmantojiet atslēgu vērtÄ«bu krātuvi

MÅ«su pirmajā atslēgu vērtÄ«bu krātuvē bija aprēķiniem nepiecieÅ”amie papildu dati. Piemēram, dažos gadÄ«jumos dalÄ«tā valsts tika noteikta pēc "vairākuma balsu" principa. Repozitorijā varētu bÅ«t visi jaunākie aÄ£enta ziņojumi par kāda objekta statusu. Pēc tam, kad mēs saņēmām jaunu ziņojumu no viena vai otra aÄ£enta, mēs varējām to saglabāt, izgÅ«t no visiem citiem aÄ£entiem ziņojumus par tā paÅ”a objekta stāvokli no krātuves un atkārtot aprēķinu.
Tālāk 4. attēlā parādīts, kā atslēgu/vērtību krātuve tika pakļauta procesora apstrādes metodei, lai pēc tam varētu apstrādāt jauno ziņojumu.

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

4. attēls. Mēs atveram piekļuvi atslēgu vērtÄ«bu krātuvei procesora apstrādes metodei (pēc tam katram skriptam, kas darbojas koplietotā stāvoklÄ«, Ŕī metode ir jāievieÅ” doProcess)

2. iespēja: CRUD API izveide Kafka straumju augÅ”daļā

Kad bija izveidota mūsu pamata uzdevumu plūsma, mēs sākām mēģināt rakstīt RESTful CRUD API mūsu koplietotajiem valsts mikropakalpojumiem. Mēs vēlējāmies, lai varētu izgūt dažu vai visu objektu stāvokli, kā arī iestatīt vai noņemt objekta stāvokli (noderīgs aizmugursistēmas atbalstam).

Lai atbalstÄ«tu visas Get State API, kad mums apstrādes laikā bija jāpārrēķina stāvoklis, mēs to ilgstoÅ”i glabājām iebÅ«vētā atslēgu vērtÄ«bu krātuvē. Å ajā gadÄ«jumā ir diezgan vienkārÅ”i ieviest Ŕādu API, izmantojot vienu Kafka Streams gadÄ«jumu, kā parādÄ«ts tālāk esoÅ”ajā sarakstā:

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

5. attēls. IebÅ«vētā atslēgu vērtÄ«bu krātuves izmantoÅ”ana, lai iegÅ«tu objekta iepriekÅ” aprēķināto stāvokli

ArÄ« objekta stāvokļa atjaunināŔana, izmantojot API, ir viegli Ä«stenojama. BÅ«tÄ«bā viss, kas jums jādara, ir izveidot Kafka producentu un izmantot to, lai izveidotu ierakstu, kas satur jauno stāvokli. Tas nodroÅ”ina, ka visi ziņojumi, kas Ä£enerēti, izmantojot API, tiks apstrādāti tāpat kā tie, kas saņemti no citiem ražotājiem (piemēram, aÄ£entiem).

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

6. attēls. Varat iestatīt objekta stāvokli, izmantojot Kafka producentu

Neliela komplikācija: Kafkai ir daudz nodalījumu

Tālāk mēs vēlējāmies sadalÄ«t apstrādes slodzi un uzlabot pieejamÄ«bu, katram scenārijam nodroÅ”inot koplietojamo mikropakalpojumu kopu. IestatÄ«Å”ana bija vienkārÅ”a: tiklÄ«dz mēs konfigurējām visas instances, lai tās darbotos ar vienu un to paÅ”u lietojumprogrammas ID (un tiem paÅ”iem sāknÄ“Å”anas serveriem), gandrÄ«z viss pārējais tika darÄ«ts automātiski. Mēs arÄ« norādÄ«jām, ka katra avota tēma sastāvēs no vairākiem nodalÄ«jumiem, lai katrai instancei varētu pieŔķirt Ŕādu nodalÄ«jumu apakÅ”kopu.

PieminÄ“Å”u arÄ« to, ka ir ierasta prakse veidot valsts veikala rezerves kopiju, lai, piemēram, atkopÅ”anas gadÄ«jumā pēc kļūmes pārsÅ«tÄ«tu Å”o kopiju uz citu instanci. Katram Å”tata veikalam pakalpojumā Kafka Streams tiek izveidota atkārtota tēma ar izmaiņu žurnālu (kas izseko vietējos atjauninājumus). Tādējādi Kafka pastāvÄ«gi dublē valsts veikalu. Tāpēc vienas vai otras Kafka Streams instances kļūmes gadÄ«jumā statusa veikalu var ātri atjaunot citā instancē, kur nonāks attiecÄ«gie nodalÄ«jumi. MÅ«su testi ir parādÄ«juÅ”i, ka tas tiek paveikts dažu sekunžu laikā, pat ja veikalā ir miljoniem ierakstu.

Pārejot no viena mikropakalpojuma ar kopÄ«gu stāvokli uz mikropakalpojumu kopu, Get State API ievieÅ”ana kļūst mazāk triviāla. Jaunajā situācijā katra mikropakalpojuma stāvokļa veikalā ir tikai daļa no kopējā attēla (tie objekti, kuru atslēgas tika kartētas uz noteiktu nodalÄ«jumu). Mums bija jānosaka, kurā instancē bija vajadzÄ«gā objekta stāvoklis, un mēs to izdarÄ«jām, pamatojoties uz pavediena metadatiem, kā parādÄ«ts tālāk:

Ne tikai apstrāde: kā mēs izveidojām izplatītu datubāzi no Kafka Streams un kas no tās izriet

7. attēls. Izmantojot straumes metadatus, mēs nosakām, no kuras instances vaicāt vēlamā objekta stāvokli; līdzīga pieeja tika izmantota ar GET ALL API

Galvenie secinājumi

Valsts veikali Kafka Streams var kalpot kā de facto izplatīta datubāze,

  • pastāvÄ«gi replicēts Kafkā
  • Šādai sistēmai var viegli izveidot CRUD API
  • Vairāku nodalÄ«jumu apstrāde ir nedaudz sarežģītāka
  • StraumÄ“Å”anas topoloÄ£ijai ir iespējams arÄ« pievienot vienu vai vairākus stāvokļa krātuves, lai saglabātu papildu datus. Å o opciju var izmantot:
  • Aprēķiniem nepiecieÅ”amo datu ilgstoÅ”a glabāŔana straumes apstrādes laikā
  • Ilgtermiņa datu glabāŔana, kas var bÅ«t noderÄ«ga nākamreiz, kad tiks nodroÅ”ināta straumÄ“Å”anas instance
  • daudz vairāk...

Å Ä«s un citas priekÅ”rocÄ«bas padara Kafka Streams piemērotu globālā stāvokļa uzturÄ“Å”anai tādā izplatÄ«tā sistēmā kā mÅ«su. Kafka Streams ir izrādÄ«jies ļoti uzticams ražoÅ”anā (kopÅ” tā izvietoÅ”anas mēs praktiski neesam zaudējuÅ”i ziņojumus), un mēs esam pārliecināti, ka tā iespējas neapstāsies!

Avots: www.habr.com

Pievieno komentāru