{"id":32632,"date":"2019-10-31T21:48:08","date_gmt":"2019-10-31T18:48:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:48:08","modified_gmt":"2019-10-31T18:48:08","slug":"ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"Inte bara bearbetning: Hur vi gjorde Kafka Streams till en distribuerad databas och vad som kom ut av det","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr!<\/p>\n

Vi p\u00e5minner om att efter boken om Kafka<\/a><\/noindex> har vi sl\u00e4ppt ett minst lika intressant verk om biblioteket Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"Inte
\n
\nF\u00f6r tillf\u00e4llet h\u00e5ller samh\u00e4llet p\u00e5 att utforska gr\u00e4nserna f\u00f6r m\u00f6jligheterna med detta kraftfulla verktyg. Nyligen publicerades en artikel som vi vill introducera er f\u00f6r. F\u00f6rfattaren delar med sig av sina egna erfarenheter om hur man skapar ett distribuerat datalager med hj\u00e4lp av Kafka Streams. Trevlig l\u00e4sning!
\n<\/a><\/noindex>
\nApache-biblioteket Kafka Streams<\/a><\/noindex> anv\u00e4nds v\u00e4rlden \u00f6ver i f\u00f6retag f\u00f6r distribuerad str\u00f6mbehandling ovanp\u00e5 Apache Kafka. En av de underskattade aspekterna av detta ramverk \u00e4r att det m\u00f6jligg\u00f6r lagring av lokalt tillst\u00e5nd som skapas genom str\u00f6mbehandling.<\/p>\n

I denna artikel kommer jag att ber\u00e4tta hur v\u00e5rt f\u00f6retag lyckades anv\u00e4nda denna m\u00f6jlighet f\u00f6r att utveckla en produkt f\u00f6r s\u00e4kerhet av molnapplikationer. Genom Kafka Streams skapade vi mikrotj\u00e4nster med delat tillst\u00e5nd, var och en av dem fungerar som en tillf\u00f6rlitlig och h\u00f6gverksam k\u00e4lla till information om tillst\u00e5ndet f\u00f6r objekt i systemet. F\u00f6r oss \u00e4r detta ett steg fram\u00e5t b\u00e5de n\u00e4r det g\u00e4ller tillf\u00f6rlitlighet och underh\u00e5ll.<\/p>\n

Om du \u00e4r intresserad av en alternativ metod som m\u00f6jligg\u00f6r anv\u00e4ndning av en central databas f\u00f6r att st\u00f6dja det formella tillst\u00e5ndet f\u00f6r dina objekt \u2013 l\u00e4s g\u00e4rna vidare, det blir intressant\u2026 <\/p>\n

Varf\u00f6r vi ans\u00e5g att det var dags att f\u00f6r\u00e4ndra v\u00e5ra angreppss\u00e4tt f\u00f6r att arbeta med delat tillst\u00e5nd <\/b><\/p>\n

Vi beh\u00f6vde st\u00f6dja tillst\u00e5ndet f\u00f6r olika objekt baserat p\u00e5 rapporter fr\u00e5n agenter (t.ex.: blev webbplatsen attackerad?). Innan \u00f6verg\u00e5ngen till Kafka Streams f\u00f6rlitade vi oss ofta p\u00e5 en central databas (+ tj\u00e4nste-API) f\u00f6r att hantera tillst\u00e5ndet. Denna metod har sina nackdelar: i datainstensiva situationer<\/a><\/noindex> blir det en verklig utmaning att st\u00f6dja konsistens och synkronisering. Databasen kan bli en flaskhals eller hamna i tillst\u00e5nd av konkurrens<\/a><\/noindex> och lida av of\u00f6ruts\u00e4gbarhet.<\/p>\n

\"Inte
\n
\nIllustration 1: en typisk scenariobild med delat tillst\u00e5nd, som intr\u00e4ffade innan \u00f6verg\u00e5ngen till
\nKafka och Kafka Streams: agenter rapporterar sina uppfattningar via API, det uppdaterade tillst\u00e5ndet ber\u00e4knas genom den centrala databasen. <\/i><\/p>\n

L\u00e4r k\u00e4nna Kafka Streams \u2013 nu \u00e4r det enkelt att skapa mikrotj\u00e4nster med delat tillst\u00e5nd. <\/b><\/p>\n

F\u00f6r ungef\u00e4r ett \u00e5r sedan best\u00e4mde vi oss f\u00f6r att noga g\u00e5 igenom v\u00e5ra arbetsscenarier f\u00f6r delat tillst\u00e5nd f\u00f6r att hantera olika problem. Vi best\u00e4mde oss f\u00f6r att prova Kafka Streams \u2013 det \u00e4r allm\u00e4nt k\u00e4nt hur skalbar, h\u00f6g tillg\u00e4nglig och fel\u00e4kta systemet \u00e4r, samt den rika str\u00f6mfunktionalitet den erbjuder (bland annat transformationer, inklusive de som beh\u00e5ller tillst\u00e5nd). Precis vad vi beh\u00f6vde, f\u00f6r att inte n\u00e4mna hur mogen och p\u00e5litlig meddelandesystemet som Kafka har blivit.<\/p>\n

Varje mikrotj\u00e4nst vi skapade med delat tillst\u00e5nd byggdes p\u00e5 en instans av Kafka Streams med en ganska enkel topologi. Den bestod av 1) en k\u00e4lla 2) en processor med ett best\u00e4ndigt nyckel-v\u00e4rde-lager 3) en str\u00f6m:<\/p>\n

\"Inte
\n
\nIllustration 2: den standardtopologi som v\u00e5ra str\u00f6minstanser f\u00f6r mikrotj\u00e4nster med delat tillst\u00e5nd f\u00f6ljer. Observera att det ocks\u00e5 finns ett lager h\u00e4r som inneh\u00e5ller metadata om schemal\u00e4ggning. <\/i><\/p>\n

Med detta nya tillv\u00e4gag\u00e5ngss\u00e4tt skapar agenter meddelanden som skickas till den ursprungliga topiken, medan konsumenterna \u2013 l\u00e5t oss s\u00e4ga, e-postnotifikationstj\u00e4nsten \u2013 tar emot det ber\u00e4knade delade tillst\u00e5ndet via str\u00f6mmen (utg\u00e5ngstopiken).<\/p>\n

\"Inte
\n
\nIllustration 3: ett nytt exempel p\u00e5 str\u00f6m av uppgifter f\u00f6r scenariet med delade mikrotj\u00e4nster: 1) agenten genererar ett meddelande som g\u00e5r till den ursprungliga Kafka-topiken; 2) mikrotj\u00e4nsten med delat tillst\u00e5nd (som anv\u00e4nder Kafka Streams) bearbetar det och skriver det ber\u00e4knade tillst\u00e5ndet till den slutliga Kafka-topiken; d\u00e4refter 3) konsumenterna tar emot det nya tillst\u00e5ndet.<\/i><\/p>\n

Hej, och detta inbyggda nyckel-v\u00e4rde-lager \u00e4r verkligen mycket anv\u00e4ndbart!<\/b><\/p>\n

Som n\u00e4mnts tidigare inneh\u00e5ller v\u00e5r topologi med delat tillst\u00e5nd ett nyckel-v\u00e4rde-lager. Vi har funnit flera s\u00e4tt att anv\u00e4nda det, och tv\u00e5 av dem beskrivs nedan.<\/p>\n

Alternativ #1: anv\u00e4ndning av nyckel-v\u00e4rde-lager vid ber\u00e4kningar.<\/b><\/i><\/p>\n

V\u00e5rt f\u00f6rsta nyckel-v\u00e4rde-lager inneh\u00f6ll hj\u00e4lpdata som vi beh\u00f6vde f\u00f6r v\u00e5ra ber\u00e4kningar. Till exempel, i vissa fall fastst\u00e4lldes det delade tillst\u00e5ndet enligt principen \"majoritetens r\u00f6ster\". I lagret kunde vi h\u00e5lla alla senaste rapporter fr\u00e5n agenter om tillst\u00e5ndet f\u00f6r ett visst objekt. N\u00e4r vi sedan fick en ny rapport fr\u00e5n en agent, kunde vi spara den, h\u00e4mta lagret av rapporter fr\u00e5n alla andra agenter om samma objekt och upprepa ber\u00e4kningen.
\nNedan i illustration 4 visas hur vi \u00f6ppnade \u00e5tkomst till nyckel-v\u00e4rde-lagret f\u00f6r processorns behandlande metod, s\u00e5 att vi sedan kunde bearbeta ett nytt meddelande.<\/p>\n

\"Inte
\n
\nIllustration 4: \u00f6ppna \u00e5tkomst till nyckel-v\u00e4rde-lagret f\u00f6r den behandlande metoden i processorn (efter detta m\u00e5ste varje scenarie som arbetar med delat tillst\u00e5nd implementera metoden doProcess<\/code>)<\/i><\/p>\n

Alternativ #2: skapa ett CRUD API ovanp\u00e5 Kafka Streams<\/b><\/i><\/p>\n

Efter att ha st\u00e4llt in v\u00e5r grundl\u00e4ggande uppgiftstr\u00f6m b\u00f6rjade vi f\u00f6rs\u00f6ka skriva ett RESTful CRUD API f\u00f6r v\u00e5ra mikrotj\u00e4nster med delat tillst\u00e5nd. Vi ville m\u00f6jligg\u00f6ra att h\u00e4mta tillst\u00e5ndet f\u00f6r vissa eller alla objekt, samt att st\u00e4lla in eller ta bort tillst\u00e5ndet f\u00f6r ett objekt (detta \u00e4r anv\u00e4ndbart f\u00f6r att st\u00f6dja backend).<\/p>\n

F\u00f6r att st\u00f6dja alla API:Get State, varje g\u00e5ng vi beh\u00f6vde ber\u00e4kna tillst\u00e5ndet p\u00e5 nytt under behandlingen, lagrade vi det under l\u00e5ng tid i det inbyggda nyckel-v\u00e4rde-lagret. I s\u00e5 fall blir det tillr\u00e4ckligt enkelt att implementera ett s\u00e5dant API med hj\u00e4lp av en enda instans av Kafka Streams, som visas i den nedanst\u00e5ende listningen:<\/p>\n

\"Inte
\n
\nIllustration 5: anv\u00e4ndning av det inbyggda nyckel-v\u00e4rde-lagret f\u00f6r att h\u00e4mta f\u00f6rber\u00e4knat tillst\u00e5nd av objektet <\/i><\/p>\n

Att uppdatera tillst\u00e5ndet f\u00f6r ett objekt via API \u00e4r ocks\u00e5 enkelt att implementera. I princip kr\u00e4vs det bara att skapa en Kafka-producent och med den g\u00f6ra en skrivning som inneh\u00e5ller det nya tillst\u00e5ndet. Detta garanterar att alla meddelanden som genereras via API behandlas p\u00e5 samma s\u00e4tt som de som skickas fr\u00e5n andra producenter (t.ex. agenter).<\/p>\n

\"Inte
\n
\nIllustration 6: st\u00e4lla in tillst\u00e5ndet f\u00f6r ett objekt kan g\u00f6ras med hj\u00e4lp av en Kafka-producent <\/i><\/p>\n

En liten komplikation: Kafka har m\u00e5nga partitioner<\/b><\/p>\n

N\u00e4sta steg var att f\u00f6rdela den belastning som \u00e4r kopplad till bearbetningen och f\u00f6rb\u00e4ttra tillg\u00e4ngligheten genom att tillhandah\u00e5lla en kluster av mikrotj\u00e4nster med delat tillst\u00e5nd f\u00f6r varje scenario. Inst\u00e4llningen var mycket enkel f\u00f6r oss: efter att vi konfigurerade alla instanser s\u00e5 att de arbetade med samma app-ID (och med samma initiala server) gjordes praktiskt taget allt annat automatiskt. Vi angav ocks\u00e5 att varje ursprunglig \u00e4mne skulle best\u00e5 av flera partitioner s\u00e5 att varje instans kunde tilldelas en delm\u00e4ngd av dessa partitioner.<\/p>\n

Jag n\u00e4mner ocks\u00e5 att det \u00e4r vanligt h\u00e4r att ta en backup av tillst\u00e5ndslager, s\u00e5 att man, till exempel, vid en \u00e5terst\u00e4llning efter ett fel kan \u00f6verf\u00f6ra denna kopia till en annan instans. F\u00f6r varje tillst\u00e5ndslager i Kafka Streams skapas ett replikerat \u00e4mne med en \u00e4ndringslogg (d\u00e4r lokala uppdateringar sp\u00e5ras). P\u00e5 s\u00e5 s\u00e4tt skyddar Kafka kontinuerligt tillst\u00e5ndslagret. D\u00e4rf\u00f6r kan tillst\u00e5ndslagret i Kafka Streams snabbt \u00e5terst\u00e4llas p\u00e5 en annan instans om en av instanserna g\u00e5r ner, dit de relevanta partitionerna flyttas. V\u00e5ra tester visade att detta g\u00f6rs p\u00e5 n\u00e5gra sekunder \u00e4ven om lagret inneh\u00e5ller miljontals poster.<\/p>\n

Att g\u00e5 fr\u00e5n en mikrotj\u00e4nst med delat tillst\u00e5nd till ett kluster av mikrotj\u00e4nster g\u00f6r det inte l\u00e4ngre s\u00e5 trivialt att implementera Get State API. I den nya situationen inneh\u00e5ller tillst\u00e5ndslagret f\u00f6r varje mikrotj\u00e4nst endast en del av den helhet som beh\u00f6vs (de objekt vars nycklar pekades p\u00e5 en specifik partition). Vi beh\u00f6vde best\u00e4mma vilken instans som inneh\u00f6ll tillst\u00e5ndet f\u00f6r det objekt vi beh\u00f6vde, och vi gjorde detta baserat p\u00e5 metadata f\u00f6r str\u00f6mmarna, som visas nedan:<\/p>\n

\"Inte
\n
\nIllustration 7: med hj\u00e4lp av metadata f\u00f6r str\u00f6mmarna best\u00e4mmer vi vilken instans vi ska h\u00e4mta tillst\u00e5ndet f\u00f6r det \u00f6nskade objektet; en liknande metod till\u00e4mpades med GET ALL API.<\/i><\/p>\n

Huvudsakliga slutsatser<\/b><\/p>\n

Tillst\u00e5ndslager i Kafka Streams kan de facto fungera som en distribuerad databas, <\/p>\n