Kaksoiskirjoitusongelma  Luotettavan, erittäin saatavilla olevan, skaalautuvan hajautetun järjestelmän rakentaminen edellyttää tiettyjen tekniikoiden, periaatteiden ja mallien noudattamista. Tällaisten järjestelmien suunnitteluun liittyy lukemattomien haasteiden ratkaiseminen. Yksi yleisimmistä ja perustavimmista ongelmista on   . kaksoiskirjoitusongelma    on haaste, joka ilmenee hajautetuissa järjestelmissä, pääasiassa silloin, kun käsitellään useita tietolähteitä tai tietokantoja, jotka on pidettävä synkronoituna. Se viittaa vaikeuteen varmistaa, että tietojen muutokset kirjoitetaan johdonmukaisesti eri tietovarastoihin, kuten tietokantoihin tai välimuistiin, aiheuttamatta ongelmia, kuten tietojen epäjohdonmukaisuuksia, ristiriitoja tai suorituskyvyn pullonkauloja. "Kaksoiskirjoitusongelma"  Mikropalveluarkkitehtuuri ja palvelukohtainen mallitietokanta tuovat sinulle monia etuja, kuten itsenäisen käyttöönoton ja skaalauksen, yksittäisiä vikoja ja mahdollisen kehitysnopeuden lisäämisen. Toiminta vaatii kuitenkin muutoksia useiden mikropalvelujen välillä, mikä pakottaa sinut miettimään luotettavaa ratkaisua ongelman ratkaisemiseksi.   Melkein todellinen esimerkki  Tarkastellaan skenaariota, jossa toimialueemme sisältää lainahakemusten hyväksymisen, arvioinnin ja ilmoitushälyttien lähettämisen asiakkaille.  Yhden vastuun periaatteen, Conwayn lain ja toimialuelähtöisen suunnittelun hengessä useiden tapahtumariippuvaisten istuntojen jälkeen koko toimialue jaettiin kolmeen aliverkkoalueeseen, joissa oli määritellyt rajatut kontekstit, joilla oli selkeät rajat, toimialuemallit ja kaikkialla esiintyvä kieli.    tehtävänä on ottaa käyttöön ja laatia uusia lainahakemuksia.   järjestelmä arvioi nämä hakemukset ja tekee päätökset annettujen tietojen perusteella. Tämä arviointiprosessi, mukaan lukien KYC/KYB, petostentorjunta ja luottoriskitarkistukset, voi olla aikaa vievä, mikä edellyttää kykyä käsitellä tuhansia hakemuksia samanaikaisesti. Tästä syystä tämä toiminto on delegoitu erilliselle mikropalvelulle, jolla on oma tietokanta, mikä mahdollistaa itsenäisen skaalauksen. Ensimmäisen Toinen  Lisäksi näitä alijärjestelmiä hallinnoi kaksi eri tiimiä, joilla kullakin on omat julkaisujaksonsa, palvelutasosopimukset (SLA) ja skaalautuvuusvaatimukset.    käytössä on erikoistunut ilmoituspalvelu, joka lähettää hälytyksiä asiakkaille.  Lisäksi Tässä on tarkennettu kuvaus järjestelmän ensisijaisesta käyttötapauksesta:  Asiakas jättää lainahakemuksen.  Lainahakemuspalvelu kirjaa uuden hakemuksen "Odottaa"-tilaan ja käynnistää arviointiprosessin välittämällä hakemuksen Arviointipalveluun.  Arviointipalvelu arvioi saapuvan lainahakemuksen ja ilmoittaa sen jälkeen päätöksestä Lainahakemuspalvelulle.  Päätöksen saatuaan Lainahakemuspalvelu päivittää lainahakemuksen tilan vastaavasti ja käynnistää Ilmoituspalvelun ilmoittamaan asiakkaalle tuloksesta.  Ilmoituspalvelu käsittelee tämän pyynnön ja lähettää ilmoitukset asiakkaalle sähköpostitse, tekstiviestillä tai muilla halutuilla viestintätapoilla asiakkaan asetusten mukaan.  Se on ensisilmäyksellä melko yksinkertainen ja primitiivinen järjestelmä, mutta sukeltakaamme kuinka Lainahakemuspalvelu käsittelee Lähetä lainahakemus -komentoa.  Voimme harkita kahta lähestymistapaa palveluvuorovaikutuksiin:    Tässä lähestymistavassa palvelu päivittää paikallisen tietokantansa (sitoutuu) ja julkaisee sitten tapahtuman tai viestin muille palveluille. First-Local-Commit-Then-Publish:    Päinvastoin, tämä menetelmä sisältää tapahtuman tai viestin julkaisemisen ennen muutosten tekemistä paikalliseen tietokantaan. Ensin-julkaise-ja sitten-paikallinen-sitoumus:  Molemmilla menetelmillä on haittapuolensa, ja ne ovat vain osittain vikaturvallisia hajautettujen järjestelmien tietoliikenteeseen.     Tämä on sekvenssikaavio ensimmäisen lähestymistavan soveltamisesta.  Tässä skenaariossa lainahakemuspalvelu käyttää   -lähestymistapaa, jossa se ensin sitoo tapahtuman ja yrittää sitten lähettää ilmoituksen toiseen järjestelmään. Tämä prosessi voi kuitenkin epäonnistua, jos esimerkiksi verkko-ongelmia ilmenee, arviointipalvelu ei ole käytettävissä tai Lainahakemuspalvelu havaitsee Muisti täynnä (OOM) -virheen ja kaatuu. Tällaisissa tapauksissa viesti katoaisi, jolloin Arviointi jätettäisiin ilman ilmoitusta uudesta lainahakemuksesta, ellei lisätoimenpiteitä toteuteta. First-Local-Commit-Then-Publish     Ja toinen.    -skenaariossa lainahakemuspalveluun liittyy merkittävämpiä riskejä. Se saattaa ilmoittaa arviointipalvelulle uudesta sovelluksesta, mutta ei voi tallentaa tätä päivitystä paikallisesti ongelmien, kuten tietokantaongelmien, muistivirheiden tai koodivirheiden vuoksi. Tämä lähestymistapa voi johtaa merkittäviin epäjohdonmukaisuuksiin tiedoissa, mikä voi aiheuttaa vakavia ongelmia riippuen siitä, kuinka Lainatarkastuspalvelu käsittelee saapuvia hakemuksia. Ensin julkaise ja sitten paikallinen sitoumus  Siksi meidän on löydettävä ratkaisu, joka tarjoaa vankan mekanismin tapahtumien julkaisemiseen ulkopuolisille kuluttajille. Mutta ennen kuin syvennymme mahdollisiin ratkaisuihin, meidän on ensin selvitettävä hajautetuissa järjestelmissä saavutettavissa olevat viestin toimitustakuutyypit.  Viestien toimitustakuu  Voimme saavuttaa neljän tyyppisiä takuita.  Ei takuita  Ei ole takeita siitä, että viesti toimitetaan perille. Lähestymistapa   koskee juuri tätä. Kuluttajat voivat saada viestejä kerran, useita kertoja tai ei koskaan. First-Local-Commit-Then-Publish  Korkeintaan kerran toimitus  Korkeintaan kerran toimitus tarkoittaa, että viesti toimitetaan määränpäähän enintään 1 kerran. Lähestymistapa   voidaan toteuttaa tällä tavalla myös uudelleenyrityskäytännöllä arvolla yksi. First-Local-Commit-Then-Publish  Ainakin kerran toimitus\Kuluttajat vastaanottavat ja käsittelevät jokaisen viestin, mutta voivat saada saman viestin useammin kuin kerran.  Täsmälleen kerran toimitus\Täsmälleen kerran toimitus tarkoittaa, että kuluttaja vastaanottaa viestin tehokkaasti kerran.  Teknisesti se on mahdollista saavuttaa Kafka-transaktioilla ja erityisellä tuottajan ja kuluttajan idempotentilla toteutuksella.  Useimmissa tapauksissa   toimitustakuu ratkaisee monia ongelmia varmistamalla, että viestit toimitetaan vähintään kerran, mutta kuluttajien on oltava kyvyttömiä. Kuitenkin, kun otetaan huomioon väistämättömät verkkohäiriöt, kaiken kuluttajalogiikan on oltava idempotenttia, jotta vältetään päällekkäisten viestien käsittely tuottajan takuista riippumatta. Siksi tämä vaatimus ei ole niinkään haitta kuin se heijastaa todellisuutta. "vähintään kerran"  Ratkaisut  Tähän ongelmaan on monia ratkaisuja, joilla on hyvät ja huonot puolensa.   Kaksivaiheinen sitoutuminen  Wikipedian mukaan Two-Phase Commit (2PC) on hajautettu tapahtumaprotokolla, jota käytetään tietojenkäsittelytieteessä ja tietokantojen hallintajärjestelmissä hajautettujen tapahtumien johdonmukaisuuden ja luotettavuuden varmistamiseksi. Se on suunniteltu tilanteisiin, joissa useiden resurssien (esim. tietokantojen) on osallistuttava yhteen tapahtumaan, ja se varmistaa, että ne kaikki sitoutuvat tapahtumaan tai kaikki keskeyttävät sen, mikä säilyttää tietojen johdonmukaisuuden. Se kuulostaa täsmälleen siltä, mitä tarvitsemme, mutta kaksivaiheisella vahvistuksella on useita haittoja:  Jos jokin osallistuva resurssi ei vastaa tai se epäonnistuu, koko prosessi voidaan estää, kunnes ongelma on ratkaistu. Tämä voi johtaa mahdollisiin suorituskyky- ja saatavuusongelmiin.  Kaksivaiheinen vahvistus ei sisällä sisäänrakennettuja viansietomekanismeja. Se luottaa ulkoisiin mekanismeihin tai manuaalisiin toimenpiteisiin vikojen käsittelemiseksi.  Kaikki nykyaikaiset tietokannat eivät tue kaksivaiheista vahvistusta.   Jaettu tietokanta  Ilmeisin ratkaisu mikropalveluarkkitehtuuriin on käyttää mallia (tai joskus jopa anti-mallia) - jaettua tietokantaa. Tämä lähestymistapa on erittäin intuitiivinen, jos tarvitset tapahtumien johdonmukaisuutta useiden eri tietokantojen taulukoiden välillä. Käytä vain yhtä jaettua tietokantaa näille mikropalveluille.  Tämän lähestymistavan haittoja ovat yhden vikakohdan käyttöönotto, itsenäisen tietokannan skaalauksen estäminen ja kyky käyttää erilaisia tietokantaratkaisuja, jotka parhaiten sopivat tiettyihin vaatimuksiin ja käyttötapauksiin. Lisäksi mikropalveluiden koodikantoihin olisi tehtävä muutoksia tukemaan tällaista hajautetun tapahtuman muotoa.   Lähtevät tapahtumat    on suunnittelumalli, jota käytetään hajautetuissa järjestelmissä viestien luotettavan etenemisen varmistamiseksi, jopa epäluotettavien viestintäjärjestelmien yhteydessä. Se sisältää tapahtumien tallentamisen määritettyyn OutboxEvents-taulukkoon samassa tapahtumassa kuin itse toiminto. Tämä lähestymistapa sopii hyvin relaatiotietokantojen ACID-ominaisuuksiin. Sitä vastoin monet No-SQL-tietokannat eivät täysin tue ACID-ominaisuuksia, vaan valitsevat sen sijaan CAP-lauseen ja BASE-filosofian periaatteet, jotka priorisoivat saatavuuden ja mahdollisen johdonmukaisuuden tiukan johdonmukaisuuden sijaan. Tapahtuman lähtevä laatikko  Lähtevät tapahtumat tarjoavat   , ja se voidaan toteuttaa useilla eri tavoilla: vähintään kerran takuun  Tapahtumalokin pyrstö  Äänestyksen julkaisija    edellyttää tietokantakohtaisten ratkaisujen, kuten CDC:n (Change Data Capture) käyttöä. Tämän lähestymistavan tärkeimmät haitat ovat: Tapahtumalokien pyrstömenetelmä  Tietokantakohtaiset ratkaisut  Lisääntynyt latenssi CDC-toteutusten erityispiirteiden vuoksi  Toinen tapa on   , joka helpottaa lähtevien viestien purkamista kyselyllä lähtevät taulukosta. Tämän lähestymistavan ensisijainen haittapuoli on mahdollisuus lisätä tietokannan kuormitusta, mikä voi johtaa korkeampiin kustannuksiin. Lisäksi kaikki No-SQL-tietokannat eivät tue tiettyjen asiakirjasegmenttien tehokasta kyselyä. Kokonaisten asiakirjojen purkaminen voi siten johtaa suorituskyvyn heikkenemiseen. Polling Publisher  Tässä on pieni sekvenssikaavio, joka selittää kuinka se toimii.    Kuuntele itseäsi  Transactional Outbox -mallin ensisijainen haaste on sen riippuvuus tietokannan ACID-ominaisuuksista. Se saattaa olla yksinkertaista tyypillisissä OLTP-tietokannoista, mutta aiheuttaa haasteita NoSQL-alueella. Tämän ratkaisemiseksi mahdollinen ratkaisu on hyödyntää liitelokia (esimerkiksi Kafka) heti pyynnön käsittelyn aloittamisesta.  Sen sijaan, että käsittelemme suoraan "lähetä lainahakemus" -komentoa, lähetämme sen välittömästi sisäiseen Kafka-aiheeseen ja palautamme sitten asiakkaalle "hyväksytty" tuloksen. Koska on kuitenkin erittäin todennäköistä, että komento on vielä käsiteltävä, emme voi heti ilmoittaa asiakkaalle tuloksesta. Tämän mahdollisen johdonmukaisuuden hallitsemiseksi voimme käyttää tekniikoita, kuten pitkiä kyselyitä, asiakaslähtöistä kyselyä, optimistisia käyttöliittymäpäivityksiä tai WebSockets- tai Server-Sent Events -tapahtumia ilmoituksiin. Tämä on kuitenkin täysin erillinen aihe, joten palataanpa alkuperäiseen aiheeseen.  Lähetimme viestin sisäisestä Kafka-aiheesta. Lainahakemuspalvelu käyttää tämän viestin – saman komennon, jonka se sai asiakkaalta – ja aloittaa käsittelyn. Ensinnäkin se toteuttaa jonkin verran liiketoimintalogiikkaa; vasta kun tämä logiikka on suoritettu onnistuneesti ja tulokset säilyvät, se julkaisee uusia viestejä julkisesta Kafka-aiheesta.  Katsotaanpa hieman pseudokoodia.   public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }    Ei hätää, koska siirtoa ei ole vielä tehty, viestiä yritetään uudelleen. Entä jos liiketoimintalogiikan käsittely epäonnistuu?    Ei hätää, koska liiketoimintalogiikka on idempotentti, se ei luo päällekkäistä lainahakemusta. Sen sijaan se yrittää lähettää viestejä uudelleen julkiseen Kafka-aiheeseen. Entä jos uusien tapahtumien lähettäminen Kafkalle epäonnistuu?    Ei hätää, koska liiketoimintalogiikka on idempotentti, se ei luo päällekkäistä lainahakemusta. Sen sijaan se lähettää viestejä uudelleen julkiselle Kafka-aiheelle ja toivoo, että offset-sitoumus onnistuu tällä kertaa. Entä jos viestejä lähetetään Kafkalle, mutta offset-sitoumus epäonnistuu?  Tämän lähestymistavan suurimpia haittoja ovat uuteen ohjelmointityyliin liittyvä monimutkaisuus, mahdollinen johdonmukaisuus (koska asiakas ei heti tiedä tulosta) ja vaatimus, että kaikki liiketoimintalogiikka on idempotentti.  Tapahtuman hankinta  Mitä tapahtuman hankinta on ja miten sitä voitaisiin soveltaa täällä? Tapahtuman hankinta on ohjelmistoarkkitehtuurimalli, jota käytetään mallintamaan järjestelmän tilaa tallentamalla kaikki sen datan muutokset muuttumattomien tapahtumien sarjana. Nämä tapahtumat edustavat tosiasioita tai tilasiirtymiä ja toimivat ainoana totuuden lähteenä järjestelmän nykyiselle tilalle. Joten teknisesti toteuttamalla tapahtumalähdejärjestelmän meillä on jo kaikki tapahtumat EventStoressa, ja kuluttajat voivat käyttää tätä EventStorea yhtenä totuuden lähteenä tapahtuneesta. Kaikkien muutosten tai tilaukseen liittyvien huolenaiheiden seuraamiseen ei tarvita erityistä tietokantaratkaisua, ainoa ongelma on istuminen lukupuolella, koska kokonaisuuden todellisen tilan saaminen edellyttää kaikkien tapahtumien toistamista.  Johtopäätös  Tässä artikkelissa tarkastelimme useita lähestymistapoja luotettavan viestinnän rakentamiseen hajautetuissa järjestelmissä. Saatamme harkita useita suosituksia rakentaessamme järjestelmiä, joilla on nämä ominaisuudet  Kehitä aina idempotentteja kuluttajia, sillä verkkovika on väistämätön.  Käytä varovasti   toimintoa ja ymmärrä takuuvaatimukset selkeästi. First-Local-Commit-Then-Publish-  Älä koskaan käytä   -lähestymistapaa, koska se voi johtaa vakavaan tietojen epäjohdonmukaisuuteen järjestelmässäsi. First-Publish-Then-Local-Commit  Jos olemassa oleva tietokannan valintapäätös hyvin todennäköisesti muuttuu tai tekninen strategia edellyttää parhaan tallennusratkaisun valitsemista ongelmalle – älä rakenna jaettuja kirjastoja sitoutumalla tietokantaratkaisuihin, kuten   . CDC  Käytä   -lähestymistapaa vakioratkaisuna vähintään kerran takuiden saavuttamiseen. Transactional Outbox  Harkitse   -lähestymistavan käyttöä, kun no-SQL-tietokantoja hyödynnetään. Kuuntele itseäsi  Seuraavalla kerralla tarkastellaan käytännöllisempää esimerkkiä Lähtevien tapahtumien käyttöönotosta. Katso  sinä!

Read My Stories

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Liian pitkä; Lukea

Make resilience your competitive advantage

Luotettava viestintä hajautetuissa järjestelmissä

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

PENANCE

Web 2.5: HackerNoon's Vision for a New Wave Internet

HEPT MOVES ON

Noonies Interview with Stefano Pavone, the Retrogaming Reporter

PENANCE

Web 2.5: HackerNoon's Vision for a New Wave Internet

HEPT MOVES ON

Noonies Interview with Stefano Pavone, the Retrogaming Reporter

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps