2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Sisällysluettelo
1. Lyhyt kuvaus tietokannan lukoista
2. Lyhyt kuvaus aukon lukituksesta
3. Kuinka rivitason lukot on toteutettu InnoDB:ssä
4. Missä olosuhteissa tietokannassa tapahtuu lukkiutuminen?
5. Kuvaile lyhyesti ratkaisua tietokannan lukkiutumiseen
Lukot ovat keskeinen ominaisuus, joka erottaa tietokantajärjestelmät tiedostojärjestelmistä. Lukitusmekanismia käytetään jaettujen resurssien samanaikaisen käytön hallintaan. Otetaanpa esimerkkinä MySQL-tietokannan InnoDB-moottori, jossa esitellään lyhyesti lukkojen ominaisuuksia.
Jos tapahtuma T1 on saanut rivin r jaetun lukon, toinen tapahtuma T2 voi saada välittömästi rivin r jaetun lukon, koska luku ei muuta rivin r tietoja. Tätä tilannetta kutsutaan lukkoyhteensopivuudeksi.Mutta jos toinen tapahtuma T3 haluaa saada yksinomaisen lukon riville r, sen on odotettava tapahtumia T1 ja T2 vapauttaakseen jaetun lukon rivillä r. Tätä tilannetta kutsutaanlukko ei yhteensopiva . Seuraava kuva näyttää jaettujen lukkojen ja eksklusiivisten lukkojen yhteensopivuuden. On havaittavissa, että X-lukko ei ole yhteensopiva minkään lukon kanssa, kun taas S-lukko on yhteensopiva vain S-lukon kanssa. On tärkeää huomata, että sekä S-lukko että X-lukko ovat rivilukkoja, ja yhteensopivuus viittaa saman tietueen (rivin) lukkojen yhteensopivuuteen.
| X | S | |
| X | Ei yhteensopiva | Ei yhteensopiva |
| S | Ei yhteensopiva | yhteensopiva |
Lukitse tarkkuus : InnoDB-tallennusmoottori tukee monirakeista lukitusta, jonka avulla tapahtumissa voidaan käyttää rivitason lukituksia ja taulukkotason lukituksia samanaikaisesti. Tukeakseen lukitustoimintoja eri tarkkuudella InnoDB-tallennuskone tukee ylimääräistä lukitusmenetelmää, jota kutsutaan tarkoituslukitukseksi. Tarkoituslukot jakavat lukitut objektit useille tasoille tarkoittavat, että tapahtumat halutaan lukita tarkemmalla tarkkuudella.
InnoDB-tallennusmoottori tukee suhteellisen yksinkertaista tarkoituslukkojen suunnittelua, ja sen intentiolukot ovat pöytätason lukkoja. Suunnittelun päätarkoitus on paljastaa tapahtuman seuraavalle riville pyydetyn lukon tyyppi. Se tukee kahta tyyppistä lukkoa:
1. Intent Shared Lock (IS-lukko), tapahtuma haluaa saada jaetut lukot tietyille taulukon riveille.
2. Tarkoituksena oleva eksklusiivinen lukitus (IX Lock), tapahtuma haluaa saada eksklusiivisia lukoja tietyille taulukon riveille.
Koska InnoDB-tallennuskone tukee rivitason lukituksia, tarkoituslukot eivät itse asiassa estä muita pyyntöjä paitsi täyden taulukon tarkistuksia. Joten taulukkotason tarkoituslukkojen ja rivitason lukkojen yhteensopivuus on seuraava:
| ON | IX | S | X | |
| ON | yhteensopiva | yhteensopiva | yhteensopiva | Ei yhteensopiva |
| IX | yhteensopiva | yhteensopiva | Ei yhteensopiva | Ei yhteensopiva |
| S | yhteensopiva | Ei yhteensopiva | yhteensopiva | Ei yhteensopiva |
| X | Ei yhteensopiva | Ei yhteensopiva | Ei yhteensopiva | Ei yhteensopiva |
lukitusalgoritmi: InnoDB-tallennuskoneessa on kolme rivin lukitusalgoritmia, jotka ovat:
1. Tietueen lukitus: Lukitse yksirivinen tietue.
2. Gap Lock: aukon lukko, lukko
3. Seuraavan näppäimen lukitus: Gap Lock + Record Lock, lukitse alue ja lukitse itse tietue.
Record Lock lukitsee aina indeksitietueet. Jos InnoDB-tallennuskoneen taulukkoon ei ole määritetty indeksiä, kun se luodaan, InnoDB-tallennuskone käyttää lukitsemiseen implisiittistä ensisijaista avainta. Next-Key Lock on lukitusalgoritmi, joka yhdistää Gap Lockin ja Record Lockin Next-Key Lock -algoritmin alla InnoDB käyttää tätä lukitusalgoritmia rivikyselyihin. Next-Key Lockia käyttävää lukitustekniikkaa kutsutaan Next-Key Lockingiksi, eikä sen suunnittelun ole tarkoitus ratkaista Phantom-ongelmaa (haamuluku). Tätä lukitustekniikkaa käyttämällä lukittu ei ole yksittäinen arvo, vaan alue, joka on Predict Lockin parannus.
Tietoja umpikujasta : Umpikuja viittaa ilmiöön, jossa kaksi tai useampi tapahtuma odottaa toisiaan kilpailun vuoksi resursseista suorituksen aikana. Ilman ulkoista voimaa asiat eivät voi edetä.
lukon päivitys :Lukon eskalaatio viittaa nykyisen lukon tarkkuuden vähentämiseen. Tietokanta voi esimerkiksi päivittää taulukon 1 000 rivin lukituksen sivun lukitukseksi tai päivittää sivun lukituksen taulukon lukitukseksi.
InnoDB-tallennusmoottorilla ei ole lukituksen päivityksen ongelmaa. Koska se ei luo rivilukkoja jokaisen tietueen perusteella, se päinvastoin hallitsee lukituksia kunkin tapahtuman jokaisen sivun perusteella bittikarttamenetelmää käyttäen. Siksi kustannukset ovat yleensä samat, lukitseeko tapahtuma yhden tietueen tai useita tietueita sivulla.
InnoDB-tallennuskoneessa on kolme rivin lukitusalgoritmia, ja aukon lukitus (Gap Lock) on yksi niistä. Välilukkoa käytetään alueen lukitsemiseen, mutta ei itse tietueita. Sen tarkoituksena on estää useita tapahtumia lisäämästä tietueita samalle alueelle, mikä voi johtaa haamulukuongelmiin.
InnoDB-rivitason lukitus toteutetaan lukitsemalla indeksin indeksimerkinnät. InnoDB käyttää rivitason lukkoja vain, kun tiedot haetaan indeksiehtojen kautta, muuten InnoDB käyttää taulukon lukituksia.
Kun tietyt taulukon rivit on lukittu, eri tapahtumat voivat käyttää eri indeksejä eri rivien lukitsemiseen. Lisäksi InnoDB käyttää rivilukkoa tietojen lukitsemiseen riippumatta siitä, käytetäänkö perusavainindeksiä, yksilöllistä indeksiä tai tavallista indeksiä.
Umpikuja viittaa ilmiöön, jossa kaksi tai useampi transaktio odottaa toisiaan kilpailun vuoksi resursseista suorituksen aikana. Ilman ulkoista voimaa asiat eivät voi edetä.Seuraava taulukko esittää klassisen umpikujan tilanteen, eli A odottaa B:tä ja B odottaa A:ta. Tämä lukkiutumisongelma on ns.AB-BA umpikuja。
| aika | Istunto A | Istunto B |
| 1 | ALKAA: | |
| 2 | mysql>SELECT * FROM t MISSÄ a = 1 PÄIVITYS; ***********1.rivi************ a:1 1 rivi sarjassa (0,00 s) | ALKAA: |
| 3 | mysql>SELECT * FROM t MISSÄ a = 2 PÄIVITYS; ***********1.rivi************ a:2 1 rivi sarjassa (0,00 s) | |
| 4 | mysql>SELECT * FROM t MISSÄ a = 2 PÄIVITYS; #odota | |
| 5 | mysql>SELECT * FROM t MISSÄ a = 1 PÄIVITYS; VIRHE 1213(40001): Umpilukko löytyi yritettäessä saada lukitus; yritä käynnistää tapahtuma uudelleen |
Yksinkertaisin tapa ratkaista lukkiutumisongelma on aikakatkaisu, eli kun kaksi tapahtumaa odottaa toisiaan, kun yksi odotusaika ylittää asetetun kynnyksen, toinen tapahtumista peruutetaan ja toinen odottava tapahtuma voi jatkua.
Aikakatkaisumekanismin lisäksi nykyiset tietokannat käyttävät yleensä myös odotusgraafi (wait graph) -menetelmää lukkiutuman havaitsemiseen. Tämä on ennakoivampi lähestymistapa lukkiutuman havaitsemiseen kuin aikakatkaisuratkaisu. Myös InnoDB-tallennusmoottori käyttää tätä lähestymistapaa. odotuskaavio edellyttää, että tietokanta tallentaa seuraavan kahden tyyppisen tiedon:
1. Lukitustietoluettelo;
2. Tapahtuman jonotuslista;
Graafi voidaan rakentaa yllä olevan linkitetyn luettelon kautta, ja jos tässä kaaviossa on silmukka, se tarkoittaa, että umpikuja on, joten resurssit odottavat toisiaan. Tämä on aktiivisempi lukkiutumisen havaitsemismekanismi. Kun jokainen tapahtuma pyytää lukkoa, se määrittää, onko silmukka olemassa pienin peruutusmäärä.
Hän on omistautunut teknologian tutkimukselle yli 30 vuoden ajan ja hallitsee useita kieliä, kuten java, linux, javascript, php, css jne. Hän on tehnyt paljon työtä avoimen lähdekoodin alalla Kehittäjän dokumentaatioasema jakaaksesi joitain teknologian kehittämisen ongelmia tulevaa käyttöä varten
