nykypäivän tietojenkäsittelyarkkitehtuureissa Apache Kafkaa käytetään usein ingressivaiheessa. Yleensä tätä vaihetta käytetään saapuvan viestin tietojen rikastamiseen ja suodattamiseen; interaktiivisia kyselyjä ei kuitenkaan ole mahdollista tehdä ennen tietojenkäsittelyputken myöhempää vaihetta. Tämä johtuu siitä, että vaikka jokainen Kafka-aiheen viesti pysyy oletusarvoisesti, ei ole vielä käytettävissä mekanismia, joka mahdollistaisi tietyn viestin nopean haun aihepiirissä.

uusien tietojen hakeminen näin varhaisessa vaiheessa putkilinjaa välttäisi kuitenkin viiveet perinteisissä prosessointiputkistoissa, jotka sisältävät yleensä pitkään käynnissä olevia erien esikäsittelyvaiheita, ja antaisi loppukäyttäjille lähes välittömän pääsyn saapuviin tietoihin.

rakennustietojen käsittelysovelluksissa Kafkan kanssa käytetään yleisesti Kafka Streams-kirjastoa, jota ylläpidetään osana Kafka-projektia. Yksi Kafka-purojen tärkeä ominaisuus ovat valtionvarastot, jotka tarjoavat tiivistelmän nopeasta paikallisesta Avainarvokaupasta, johon voidaan lukea ja kirjoittaa Kafka-puroilla käsiteltäviä viestejä käsiteltäessä. Nämä Avainarvosäilöt voidaan jatkuvasti täyttää uusilla viesteillä Kafka-aiheesta määrittelemällä sopiva stream-prosessori, jotta viestit voidaan nyt nopeasti hakea alla olevasta aiheesta.

tämän Kafka Streams-toiminnon päälle luomme yhtenäisen REST API: n, joka tarjoaa yhden kyselevän päätepisteen tietylle Kafka-aiheelle.

yhteenvetona voidaan todeta, että yhdistämällä Kafka Streams-prosessorit valtiollisiin varastoihin ja HTTP-palvelimeen voidaan tehokkaasti muuttaa mikä tahansa Kafka-aihe nopeasti vain lukuavaimen arvoiseksi varastoksi.

Kafka Streams on rakennettu kirjastoksi, joka voidaan upottaa itsenäiseen Java-tai Scala-sovellukseen. Sen avulla kehittäjät voivat määritellä stream prosessorit, jotka suorittavat tietojen muunnoksia tai aggregaatioita Kafka viestejä, varmistaa, että jokainen syöttöviesti käsitellään täsmälleen kerran. Käyttämällä Kafka Streams DSL, joka on saanut vaikutteita Java Stream API, stream prosessorit, ja valtion tallentaa voidaan joustavasti ketjuttaa.

lisäksi käynnistettäessä useita Kafka-Streamipohjaisen sovelluksen instansseja prosessit muodostavat automaattisesti kuormitustasapainotteisen, erittäin saatavilla olevan prosessointiklusterin ilman, että ne riippuvat muista ulkoisista järjestelmistä kuin Kafkasta.

valtion myymälöitä käyttävän Kafka Streams-sovelluksen arkkitehtuurin havainnollistamiseksi kuvitelkaa seuraava skenaario: rautatieoperaattorina joka kerta, kun asiakas varaa matkan verkkosivustollamme, Kafka-aiheeseen lisätään uusi viesti, joka koostuu asiakastunnuksesta ja aikaleimasta. Erityisesti yksi tai useampi Kafka-tuottaja lisää nämä viestit aiheeseen, jossa on yhdeksän osiota. Koska asiakkaan tunnus on valittu jokaisen viestin avaimeksi, tietylle asiakkaalle kuuluvat tiedot lisätään aina aiheen samaan osioon. Epäsuorasti Kafkan tuottajat käyttävät DefaultPartitioner osoittaakseen viestejä osioille.

nyt oletetaan, että meillä on Kafka Streams-sovellus, joka lukee viestejä tästä aiheesta ja jatkaa niitä Valtion kaupassa. Koska jokaisen viestin avain koostuu vain asiakastunnuksesta, vastaava arvo valtion kaupassa on aina asiakkaan viimeisimmän varauksen aikaleima. Jotta saavutetaan mahdollisimman suuri rinnakkainen käsittely, voimme aloittaa jopa yhdeksän esiintymiä Kafka Streams sovellus. Tässä tapauksessa, jokainen sovellus esiintymä annetaan täsmälleen yksi aihe osioita. Jokaiselle tuloosiolle Kafka Streams luo erillisen valtionvaraston, joka puolestaan pitää sisällään vain kyseiseen osioon kuuluvien asiakkaiden tiedot.

tuloksena oleva sovellusarkkitehtuuri on esitetty alla olevassa kaaviossa.

sovelluksessa on mahdollista käyttää joko muistissa olevia tai pysyviä valtionvarastoja. Toiminnot in-memory state stores ovat vielä nopeampia verrattuna pysyviä variantti, joka sisäisesti käyttää RocksDB tallentaa. Toisaalta pysyvät valtionvarastot voidaan palauttaa nopeammin, jos Kafka Streams-sovellus on epäonnistunut ja se on käynnistettävä uudelleen. Lisäksi tallennuskohtaista datamäärää ei rajoita päämuistin määrä, kun käytetään pysyviä valtiovarastoja.

meidän skenaariossamme ei tarvitse olla changelog-aihetta, joka tallentaa kirjoitustoiminnot valtion varastoihin: kaikki tiedot, joita tarvitaan valtion varaston palauttamiseen, voidaan saada alkuperäisestä syöttöaiheesta.

lisäämällä REST-päätepisteen stream-prosessoreihin

tähän mennessä esitetyllä arkkitehtuurilla meillä on yhdeksän valtion varastoa, joiden avulla voidaan hakea kulloiseenkin input topic-osioon kuuluvien asiakkaiden viimeisin varauspäivä.

nyt, jotta tämä tieto olisi saatavilla Kafka Streams-prosessoreiden ulkopuolelta, meidän on paljastettava palvelun päätepiste jokaisessa stream processorin sovellusasteessa ja vastattava Kafka Streamsin hallinnoimasta sisäisestä valtionvarastosta tuleviin pyyntöihin.

lisävaatimuksena emme voi olettaa, että hakeva sovellus tietää, mikä Kafka Streams-instanssi on tällä hetkellä vastuussa tietyn asiakkaan tietojen käsittelystä. Näin ollen jokainen palvelun päätepiste on vastuussa kyselyn ohjaamisesta oikeaan sovellustilanteeseen, jos asiakastiedot eivät ole paikallisesti saatavilla.

päätimme toteuttaa palvelun päätepisteen REST API: na, jonka etuna on se, että se on saatavilla mistä tahansa HTTP-ohjelmaa tukevasta asiakkaasta ja mahdollistaa läpinäkyvän kuormanpalauttimen lisäämisen erittäin helposti.

KafkaStreams objekti, joka on saatavilla jokaisessa Kafka Streams-sovelluksessa, tarjoaa lukuoikeuden kaikkiin paikallisiin myymälöihin ja voi myös määrittää sovellusesineen, joka vastaa tietystä asiakastunnuksesta. Kun tätä objektia käytetään LEPOPALVELUN rakentamiseen, arkkitehtuuri näyttää seuraavalta:

tiivistettynä ehdotetussa arkkitehtuurissamme hyödynnetään Kafka-aiheita viestien luotettavasti tallentamiseen levossa ja ylläpidetään toista edustusta tiedoista valtion varastoissa nopeiden kyselyiden tueksi.

sovelluksen skaalautuvuuden varmistaminen

skaalautuvan sovelluksen saamiseksi on varmistettava, että käsittelykuorma on tasapuolinen kaikissa Kafka Streams-sovelluksen esiintymissä. Yksittäisen stream-prosessorin kuormitus riippuu sen käsiteltävien tietojen ja kyselyjen määrästä.

tarkemmin ottaen on tärkeää valita Kafka-aiheelle osiointijärjestelmä siten, että saapuvien viestien ja kyselyjen kuormitus on hyvin tasapainossa kaikissa osioissa ja näin ollen myös kaikissa stream-prosessoreissa.

Jos käytetään muistitilavarastoja, aiheen osioiden määrän on oltava riittävän suuri, jotta jokainen stream-prosessori pystyy pitämään yhden osion datamäärän päämuistissa. Huomaa, että vikatilanteessa stream-prosessori saattaa jopa joutua pitämään kahta osiota päämuistissa.

virransuoritinten vikojen huomioon ottamiseksi valmiuskopioiden määrä voidaan määrittää käyttämällä num.standby.replicas asetusta Kafka-Streameihin, mikä varmistaa, että myös muut stream-prosessorit tilaavat viestejä tietyltä prosessoriosiolta. Vikatilanteessa nämä prosessorit voivat nopeasti ottaa vastatakseen kyselyihin sen sijaan, että ne aloittaisivat valtiovaraston rekonstruoinnin vasta, kun vika on jo tapahtunut.

lopulta halutun määrän stream-suorittimia on sovittava käytettävissä olevaan laitteistoon. Jokaista stream processor – sovellusesitystä varten on varattava vähintään yksi suoritinydin. Multicore-järjestelmissä on mahdollista lisätä streamausketjujen määrää sovellusesimerkkiä kohden, mikä vähentää erillisen Java-sovelluksen käynnistämisestä johtuvia kustannuksia suoritinydintä kohden.