【Descrierea problemei】
Când utilizatorii folosesc APP-ul, pagina este foarte blocată și vor da click aleatoriu, deoarece interfața nu face trimiteri repetate, vor exista mai multe cereri identice, în stratul de servicii, un fir nu inserează complet, iar celălalt verifică, gol. Așa că am introdus și eu unul. Inițial, toată lumea avea unul, dar un vânzător avea trei, ceea ce ducea la erori de logică de business. Pentru procesarea trimiterilor malițioase, acest lucru se poate face în partea de front-end, iar în partea de back-end pot exista și soluții mature.
【Soluție】1. Folosirea constrângerilor de unicitate pentru a rezolva problema idempotenței tranzacțiilor, setarea constrângerilor de unicitate, iar dacă există un scenariu de commit-uri repetate, excepțiile de la constrângerile de unicitate vor fi aruncate la nivelul bazei de date, iar logica de afaceri nu va fi distrusă. Constrângerile de unicitate asupra compoziției mai multor câmpuri sunt, de asemenea, acceptabile.
Autentificarea cu hyperlink este vizibilă.
Cele de mai sus sunt pentru a crea setări anti-duplicare la nivelul bazei de date.
2. Realizarea setărilor anti-duplicare la nivel de cod. De multe ori, se spune că constrângerea unicității bazei de date va afecta eficiența inserării datelor, deoarece fiecare inserție necesită o judecată la nivelul bazei de date. Prin urmare, judecând după nivelul codului, practica comună la nivel de cod este să selectezi mai întâi și apoi să se insereze, dar dacă există un scenariu de concurență mare, vor exista totuși commit-uri repetate. Poți adăuga sincronizat codului logic, astfel încât, în scenarii cu concurență mare, să selectezi mai întâi și apoi să introduci efectul. Dar eficiența nu este mare, iar paralela devine serială. Mecanismul de blocare DCL poate fi folosit. (Ai observat că metoda de creare a unui singur obiect în modul de copiere a cazului este foarte similară, mai întâi judecă dacă obiectul există, dacă nu există, creează-l, altfel nu îl creați), mecanismul natural de blocare DCL este mai eficient.
#分布式锁
Încuietorile distribuite pot fi, de asemenea, folosite pentru a rezolva problema, utilizate frecvent de Redis și Zookeeper. Această secțiune explică cum să implementezi încuietori distribuite folosind Redis.
Există o operație de comandă setNx în Redis, dacă nu există, este o valoare setată, iar 1 este returnat. Dacă există, nu se setează și returnează 0.
Folosind funcția single-threading a Redis, scena cu concurență mare este transformată într-un serial prin coada de mesaje.
Totuși, există capcane în lacătele distribuite, așa că trebuie să fii atent.
Autentificarea cu hyperlink este vizibilă.
3. Mecanismul MVCC?
3.1 Ce este mecanismul MVCC?
MVCC este un mecanism de control al concurenței cu mai multe versiuni.
3.2 Ce probleme pot fi rezolvate?
Mecanismul de blocare poate controla operațiunile concurente, dar overhead-ul sistemului este mare, iar MVCC poate înlocui încuietorile la nivel de rând în majoritatea cazurilor, ceea ce poate reduce overhead-ul sistemului și îmbunătățește performanța.
Autentificarea cu hyperlink este vizibilă.
4. Există, de asemenea, o problemă a idempotenței în mesaje
De exemplu, cum să previi consumul repetat de mesaje?
În middleware-ul de mesaje din MQ, acestea trebuie înțelese și înțelese.
|
Postat pe 04.12.2018 13:29:37
|
|
|
Proprietarul|
Postat pe 17.03.2021 10:27:09
|
