Starea comună, după cum se știe, este necesară protejării. În caz contrar, firul paralel îl poate "sparge". Acest lucru se aplică și aplicațiilor web. În ciuda lipsei unui sprijin normal pentru paralelism în majoritatea limbilor web (PHP, Python, Ruby), concurența în aplicațiile web este suficientă. Cererile vin în paralel pe serverul web, se execută în paralel cu diferite procesoare etc. Din acest motiv, următorul cod este incorect:
Există două modalități fundamentale diferite de a asigura integritatea datelor: blocare pesimistă și optimistă. Blocare pesimistĺ presupune că, dacă vom executa codul, performanța competitivă a ceea ce poate duce la „eșec“ a datelor, este necesar să se excludă executarea sa competitivă. Adică, serializați fluxurile în acest moment. Acest lucru se realizează fie cu ajutorul blocurilor distribuite sau a tranzacțiilor din baza de date.
La noi în sistem există o mică bibliotecă care permite implementarea blocării exclusive a codului. Utilizarea sa arată astfel:
Blocarea pesimistă este similară principiului Murphy. Se presupune că, dacă se poate întâmpla ceva rău, se va întâmpla în mod necesar. Spre deosebire de blocarea pesimistă, optimistă presupune că în timpul actualizării înregistrării în baza de date vom fi singurii care o schimbă. În cele mai multe cazuri, este, deci optimismul este justificat. Cu toate acestea, în timpul UPDATE, verificăm dacă înregistrarea sa schimbat de când a fost citită. Și dacă sa schimbat, atunci trebuie să citim cea mai recentă versiune a înregistrării din baza de date și să ne repetă operațiunea cu ea.
punerea în aplicare
Acest lucru este destul de simplu. Este suficient să stocați identificatorul versiunii cu fiecare înregistrare din baza de date și să verificați dacă nu sa schimbat și să îl schimbați în timpul înregistrării. Algoritmul este următorul.
În această metodă, când actualizăm, verificăm dacă versiunea nu sa schimbat, ceea ce înseamnă că nimeni nu a schimbat înregistrarea în baza de date. În cazul în care versiunea sa modificat, suntem obligați să noțilam clientul.
Dar aici este o lovitură. Ce va face clientul cu această excepție?
În cazul în care implementați o blocare optimistă, atunci modelul trebuie să preia logica salvării obiectelor, altfel veți umfla scrierea clienților. Modelul ar trebui să ofere o interfață diferită și mai convenabilă pentru a funcționa pe obiecte. Folosind funcțiile PHP / 5.3, puteți face următoarele:
Avantajele "optimistilor fata de pesimiști"
Nu blochează clienții care nu modifică starea
Imaginați-vă acest cod:
Elimină clientul de necesitatea de a avea grijă de blocarea
În cazul blocării optimiste, codul clientului este mai simplu și acest cod este necesar mai puțin. Mai puțin cod → mai puține probleme.
Garanția protejează datele
Când operați bloc'ami, pot exista patru tipuri de probleme:
- luați prea puține încuietori (date rupte);
- luați prea multe încuietori (blocaj, înfometare);
- veți lua loci greșit (date rupte);
- luați aceste loki, dar nu în aceeași ordine (blocaj).
Dacă doriți să blocare pesimistă funcționează bine în sisteme mai mari, este necesar ca programatorii care scrie cod client-side, în mod clar conștient de esența procesului concurențial, au fost foarte atenți, și că au avut 5 kilograme de creier. Cel mai probabil, ca majoritatea celorlalți oameni normali, creierul cântărește doar 3 kilograme. Așadar, nu împingeți problema asupra modelului, și anume, pentru a asigura integritatea datelor.
Cel mai rău lucru care se poate întâmpla în cazul unei blocări optimiste - clientul va primi o excepție. Cel mai rău lucru care se poate întâmpla în cazul blocării pesimiste este că "rupeți" datele.
Ce alegeți?