Per anmodning er her en oversigt over vores problem, og hvordan vi løste det:
I vores system oprettede vi en brugerdefineret dokumentlåsningsrutine (ved hjælp af redis-lock), hvor følgende skete i denne præcise (forkerte) rækkefølge:
FORKERT RÆKKEFØLGE AF OPERATIONER:
- Kundeanmodning modtaget
- Dokumentet er låst
- Dokumentet er hentet
- Dokumentet er redigeret
- Dokumentet er låst op
- Kundeanmodning løst
- Dokumentet er gemt
Når du ser det skrevet ud, er problemet indlysende:vi gemte vores dokumenter uden for vores dokumentlås.
Lad os antage, at #6 tager 100 ms i vores system. Det er et vindue på 100 ms, hvor hvis andre anmodninger griber det samme dokument, vil vi have en gem-konflikt (titelfejlen i dette spørgsmål er dybest set en gem-konflikt IMHO).
Med andre ord/eksempel:I vores system greb Request A version 1 af Dokument X, redigerede det og låste det derefter op, men før Request A gemte dokumentet, greb Request B Document X og steg det til version 2 (læs op på Mongo versioner for mere information om dette). Så løser anmodning A sin klientanmodning og går til at gemme dokument X, men den forsøger at gemme version 1, og nu ser den, at den har version 2, og dermed fejlen ovenfor.
Så rettelsen er nem. Gem dine dokumenter inde i din lås. (I ovenstående eksempel, flyt #7 til før #5. Se nedenfor.)
KORREKT/FAST Rækkefølge for OPERATIONER
- Kundeanmodning modtaget
- Dokumentet er låst
- Dokumentet er hentet
- Dokumentet er redigeret
- Dokumentet er gemt
- Dokumentet er låst op
- Kundeanmodning løst
(Du kan argumentere for, at #6 og #7 skal byttes, men det er uden for Mongo/Mongoose/dette spørgsmål.)
Jeg vil lade dette spørgsmål være ubesvaret i et stykke tid og se, om nogen kan kaste lys over en bedre måde at isolere den relevante kode og fejlfinde på dette problem. I vores tilfælde var dette et meget systemisk problem og MEGET udfordrende at fejlfinde for vores færdighedsniveau på det tidspunkt.