Tapahtumien käsittely - Transaction processing

Tapahtumien käsittelyn on tietoa käsittelyä tietotekniikassa , joka on jaettu yksittäisiin, jakamattomia toimintoja kutsutaan liiketoimet . Jokaisen tapahtuman on onnistuttava tai epäonnistuttava kokonaisena kokonaisuutena; se ei voi koskaan olla vain osittain valmis.

Kun esimerkiksi ostat kirjan online -kirjakaupasta, vaihdat rahaa (hyvityksen muodossa) kirjaan. Jos luottosi on hyvä, sarja asiaan liittyviä toimintoja varmistaa, että saat kirjan ja kirjakauppa saa rahat. Kuitenkin, jos yksi sarjan toiminto epäonnistuu vaihdon aikana, koko vaihto epäonnistuu. Et saa kirjaa ja kirjakauppa ei saa rahojasi. Vaihdon tasapainottamisesta ja ennakoitavuudesta vastaavaa tekniikkaa kutsutaan tapahtumien käsittelyksi. Tapahtumat varmistavat, että datalähtöisiä resursseja ei päivitetä pysyvästi, elleivät kaikki tapahtumayksikön toiminnot ole suoritettu loppuun. Yhdistämällä joukko asiaan liittyviä toimintoja yksiköksi, joka joko onnistuu tai epäonnistuu kokonaan, voidaan yksinkertaistaa virheiden palauttamista ja tehdä sovelluksesta luotettavampi.

Tapahtumien käsittelyjärjestelmät koostuvat tietokonelaitteistosta ja -ohjelmistosta, joka isännöi tapahtumakeskeistä sovellusta, joka suorittaa liiketoiminnan harjoittamiseen tarvittavat rutiinitapahtumat. Esimerkkejä ovat järjestelmät, jotka hallitsevat myyntitilausten syöttämistä, lentoyhtiöiden varauksia, palkanlaskentaa, työntekijöiden tietoja, valmistusta ja toimitusta.

Koska suurin osa, vaikkakaan ei välttämättä kaikki, tapahtumien käsittely on nykyään vuorovaikutteista, termiä pidetään usein synonyyminä online -tapahtumien käsittelyyn .

Kuvaus

Tapahtumakäsittely on suunniteltu ylläpitämään järjestelmän eheys (tyypillisesti tietokanta tai jotkin modernit tiedostojärjestelmät ) tunnetussa, johdonmukaisessa tilassa varmistamalla, että järjestelmän toisistaan ​​riippuvat toiminnot joko suoritetaan onnistuneesti tai kaikki peruutetaan onnistuneesti.

Ajattele esimerkiksi tyypillistä pankkitapahtumaa, joka sisältää 700 dollarin siirtämisen asiakkaan säästötililtä asiakkaan sekkitilille. Tämä tapahtuma sisältää vähintään kaksi erillistä operaatiota tietokoneen kannalta: veloitetaan säästötili 700 dollarilla ja hyvitetään shekkitilillä 700 dollarilla. Jos toinen operaatio onnistuu, mutta toinen ei, pankin kirjat eivät ole tasapainossa päivän päätteeksi. Siksi on oltava keino varmistaa, että molemmat operaatiot onnistuvat tai molemmat epäonnistuvat, jotta pankin tietokantaan ei koskaan kohdistu epäjohdonmukaisuutta.

Tapahtumien käsittely yhdistää useita yksittäisiä toimintoja yhteen jakamattomaan tapahtumaan ja varmistaa, että joko kaikki tapahtuman toiminnot suoritetaan virheettömästi tai mikään niistä ei ole. Jos jotkin toiminnot on suoritettu loppuun, mutta virheitä ilmenee, kun toisia yritetään, tapahtumien käsittelyjärjestelmä "palauttaa" kaikki tapahtuman toiminnot (myös onnistuneet), poistamalla näin kaikki tapahtuman jäljet ​​ja palauttamalla järjestelmän johdonmukaiseen, tunnettuun tilaan, jossa se oli ennen tapahtuman käsittelyn aloittamista. Jos kaikki tapahtuman toiminnot suoritetaan onnistuneesti, järjestelmä sitoutuu tapahtumaan ja kaikki tietokannan muutokset tehdään pysyviksi; tapahtumaa ei voi peruuttaa, kun tämä on tehty.

Tapahtumien käsittely suojaa laitteisto- ja ohjelmistovirheiltä, ​​jotka saattavat jättää tapahtuman osittain valmiiksi. Jos tietokonejärjestelmä kaatuu tapahtuman keskellä, tapahtumien käsittelyjärjestelmä takaa, että kaikki sitoutumattomien tapahtumien toiminnot peruutetaan.

Yleensä tapahtumat lasketaan samanaikaisesti. Jos ne ovat päällekkäisiä (eli niiden on koskettava samaa tietokannan osaa), tämä voi aiheuttaa ristiriitoja. Jos esimerkiksi yllä olevassa esimerkissä mainitulla asiakkaalla on 150 dollaria säästötilillään ja hän yrittää siirtää 100 dollaria toiselle henkilölle siirtäen samalla 100 dollaria sekkitilille, vain yksi heistä voi onnistua. Tapahtumien pakottaminen käsittelemään peräkkäin on kuitenkin tehotonta. Siksi tapahtumien käsittelyn samanaikaiset toteutukset on ohjelmoitu takaamaan, että lopputulos heijastaa konfliktitonta lopputulosta, sama kuin mitä voitaisiin saavuttaa, jos tapahtumat suoritetaan peräkkäin missä tahansa järjestyksessä (ominaisuus, jota kutsutaan sarjoitettavuusksi ). Esimerkissämme tämä tarkoittaa sitä, että riippumatta siitä, mikä tapahtuma on annettu ensimmäisenä, joko siirto toiselle henkilölle tai siirto sekkitilille onnistuu, kun taas toinen epäonnistuu.

Metodologia

Kaikkien tapahtumien käsittelyjärjestelmien perusperiaatteet ovat samat. Terminologia voi kuitenkin vaihdella tapahtumien käsittelyjärjestelmästä toiseen, ja alla käytetyt termit eivät välttämättä ole yleispäteviä.

Palautus

Tapahtumien käsittelyjärjestelmät varmistavat tietokannan eheyden tallentamalla tietokannan välitiloja, kun sitä muutetaan, ja käyttämällä sitten näitä tietueita palauttamaan tietokanta tunnettuun tilaan, jos tapahtumaa ei voida suorittaa. Esimerkiksi järjestelmä kopioi tietokannan tiedot ennen sen muuttamista tapahtumalla ennen kuin tapahtuma voi tehdä muutoksia (tätä kutsutaan joskus ennen kuvaa ). Jos jokin tapahtuman osa epäonnistuu ennen sen tekemistä, näitä kopioita käytetään palauttamaan tietokanta tilaan, jossa se oli ennen tapahtuman alkua.

Rullaa eteenpäin

On myös mahdollista pitää erillistä päiväkirjaa kaikista tietokannan hallintajärjestelmän muutoksista. (kutsutaan joskus kuvien jälkeen ). Tätä ei vaadita epäonnistuneiden tapahtumien peruuttamiseen, mutta se on hyödyllinen tietokannan hallintajärjestelmän päivittämisessä tietokannan vian sattuessa, joten jotkin tapahtumien käsittelyjärjestelmät tarjoavat sen. Jos tietokannan hallintajärjestelmä epäonnistuu kokonaan, se on palautettava viimeisimmästä varmuuskopiosta. Varmuuskopiointi ei kuvaa varmuuskopioinnin jälkeen tehtyjä liiketoimia. Kuitenkin, kun tietokannan hallintajärjestelmä on palautettu, jälkikuvien päiväkirjaa voidaan soveltaa tietokantaan ( rollforward ) tietokannan hallintajärjestelmän saattamiseksi ajan tasalle. Kaikki vikahetkellä käynnissä olevat tapahtumat voidaan sitten peruuttaa. Tuloksena on tietokanta johdonmukaisessa, tunnetussa tilassa, joka sisältää kaikkien epäonnistumiseen asti tehtyjen tapahtumien tulokset.

Lukkiutumiset

Joissakin tapauksissa kaksi tapahtumaa voi käsittelyn aikana yrittää päästä samaan tietokannan osaan samanaikaisesti tavalla, joka estää niitä etenemästä. Esimerkiksi tapahtuma A voi käyttää tietokannan osaa X ja tapahtuma B voi käyttää tietokannan osaa Y. Jos tapahtuma A yrittää tässä vaiheessa päästä tietokannan osaan Y, kun taas tapahtuma B yrittää päästä osioon X, tapahtuu umpikuja , eikä kumpikaan tapahtuma voi siirtyä eteenpäin. Tapahtumien käsittelyjärjestelmät on suunniteltu havaitsemaan nämä umpikujat, kun ne ilmenevät. Yleensä molemmat tapahtumat peruutetaan ja palautetaan takaisin, ja sitten ne aloitetaan uudelleen eri järjestyksessä automaattisesti, jotta umpikuja ei toistu. Tai joskus vain yksi lukkiutuneista tapahtumista peruutetaan, palautetaan ja käynnistetään automaattisesti uudelleen lyhyen viiveen jälkeen.

Lukkiutuminen voi tapahtua myös kolmen tai useamman tapahtuman yhteydessä. Mitä enemmän tapahtumia, sitä vaikeampaa niiden havaitseminen on siinä määrin, että tapahtumien käsittelyjärjestelmät havaitsevat käytännön rajan havaitsemilleen umpikujille.

Korvaava kauppa

Järjestelmissä, joissa sitoutumis- ja palautusmekanismeja ei ole saatavilla tai ne eivät ole toivottavia, kompensointitapahtumaa käytetään usein kumoamaan epäonnistuneet tapahtumat ja palauttamaan järjestelmä edelliseen tilaan.

ACID -kriteerit

Jim Gray määritti luotettavan tapahtumajärjestelmän ominaisuudet 1970 -luvun lopulla lyhenteellä ACID - atomisuus, johdonmukaisuus, eristys ja kestävyys.

Atomisiteetti

Tapahtuman muutokset tilaan ovat atomisia: joko kaikki tapahtuu tai ei tapahdu. Näihin muutoksiin kuuluvat tietokannan muutokset, viestit ja anturitoiminnot.

Johdonmukaisuus

Johdonmukaisuus : Tapahtuma on tilan oikea muutos. Ryhmänä tehdyt toimet eivät riko mitään tilaan liittyviä eheysrajoituksia.

Eristäytyminen

Vaikka tapahtumat suoritetaan samanaikaisesti, jokaiselle tapahtumalle T näyttää siltä, ​​että muut suorittavat joko ennen T: tä tai sen jälkeen, mutta eivät molempia.

Kestävyys

Kun tapahtuma on suoritettu onnistuneesti (sitoutuu), sen muutokset tietokantaan selviävät epäonnistumisista ja säilyttävät muutokset.

Edut

Tapahtumien käsittelyllä on seuraavat edut:

  • Se mahdollistaa tietokoneen resurssien jakamisen monien käyttäjien kesken
  • Se siirtää työnkäsittelyn ajan siihen, kun laskentaresurssit ovat vähemmän varattuja
  • Se välttää tietojenkäsittelyresurssien joutokäynnin ilman ihmisen minuutti-minuutti-vuorovaikutusta ja valvontaa
  • Sitä käytetään kalliissa tietokoneluokissa auttamaan kustannusten lyhentämisessä pitämällä kalliiden resurssien korkea käyttöaste

Haitat

  • Niillä on suhteellisen kalliit asennuskulut
  • Vakiomuotoja ei ole
  • Laitteiston ja ohjelmiston yhteensopimattomuus

Toteutukset

Standard kauppa-käsittelyn ohjelmistoja , kuten IBM: n Information Management System , oli ensimmäinen kehitetty 1960-luvulla, ja oli usein läheisesti kytketty erityisesti tietokantojen hallintajärjestelmät . Asiakas -palvelinlaskenta toteutti samanlaisia ​​periaatteita 1980 -luvulla menestyksekkäästi. Kuitenkin viime vuosina hajautetun asiakas -palvelin -mallin ylläpito on tullut huomattavasti vaikeammaksi. Kun tapahtumien määrä kasvoi vastauksena erilaisiin verkkopalveluihin (erityisesti Web ), yksi hajautettu tietokanta ei ollut käytännöllinen ratkaisu. Lisäksi useimmat online -järjestelmät koostuvat kokonaisesta joukosta ohjelmia, jotka toimivat yhdessä, toisin kuin tiukka asiakas -palvelin -malli, jossa yksi palvelin pystyy käsittelemään tapahtumien käsittelyn. Nykyään on saatavana useita tapahtumien käsittelyjärjestelmiä, jotka toimivat ohjelmien välisellä tasolla ja jotka ulottuvat suuriin järjestelmiin, mukaan lukien keskusyksiköt .

Yksi ratkaisu on X/Open Distributed Transaction Processing (DTP) (katso myös Java Transaction API (JTA). Kuitenkin yksityiset tapahtumien käsittelyympäristöt, kuten IBM: n CICS, ovat edelleen erittäin suosittuja, vaikka CICS on kehittynyt sisältämään myös avoimia teollisuusstandardeja .

Termiä äärimmäinen tapahtumakäsittely (XTP) käytettiin kuvaamaan tapahtumien käsittelyjärjestelmiä, joilla on epätavallisen haastavia vaatimuksia, erityisesti suoritusteho (tapahtumat sekunnissa). Tällaiset järjestelmät voidaan toteuttaa hajautetun tai klusterityylisen arkkitehtuurin kautta. Sitä käytettiin ainakin vuoteen 2011 mennessä.

Viitteet

Lue lisää

  • Gerhard Weikum, Gottfried Vossen, Tapahtumatietojärjestelmät: teoria, algoritmit ja samanaikaisuuden hallinnan ja palautuksen käytäntö , Morgan Kaufmann, 2002, ISBN  1-55860-508-8
  • Jim Gray , Andreas Reuter, Transaction Processing-Concepts and Techniques, 1993, Morgan Kaufmann, ISBN  1-55860-190-2
  • Philip A.Bernstein, Eric Newcomer, Principles of Transaction Processing, 1997, Morgan Kaufmann, ISBN  1-55860-415-4
  • Ahmed K.Elmagarmid (toimittaja), Transaction Models for Advanced Database Applications, Morgan-Kaufmann, 1992, ISBN  1-55860-214-3

Ulkoiset linkit