Per begäran, här är en översikt över vårt problem och hur vi löste det:
I vårt system skapade vi en anpassad dokumentlåsningsrutin (med redis-lock), där följande hände i denna exakta (felaktiga) ordning:
FEL ORDNING FÖR OPERATIONER:
- Kundförfrågan mottagen
- Dokument låst
- Dokumentet hämtat
- Dokumentet har redigerats
- Dokument upplåst
- Kundförfrågan löst
- Dokumentet har sparats
När du ser det utskrivet är problemet uppenbart:vi sparade våra dokument utanför vårt dokumentlås.
Låt oss anta att #6 tar 100ms i vårt system. Det är ett 100ms fönster där om någon annan förfrågan tar tag i samma dokument, kommer vi att ha en räddningskonflikt (titelfelet i denna fråga är i grunden en räddningskonflikt IMHO).
Med andra ord/exempel:i vårt system tog Request A version 1 av Dokument X, redigerade den och låste upp den, men innan Request A sparade dokumentet tog Request B Dokument X och ökade den till version 2 (läs upp på Mongo versioner för mer information om detta). Sedan löser Request A sin klientförfrågan och går till att spara dokument X, men den försöker spara version 1, och nu ser den att den har version 2, och därmed felet ovan.
Så åtgärden är enkel. Spara dina dokument i ditt lås. (I exemplet ovan, flytta #7 till före #5. Se nedan.)
KORREKT/FAST ORDNING FÖR OPERATIONER
- Kundförfrågan mottagen
- Dokument låst
- Dokumentet hämtat
- Dokumentet har redigerats
- Dokumentet har sparats
- Dokument upplåst
- Kundförfrågan löst
(Du kan argumentera för att #6 och #7 bör bytas ut, men det ligger utanför Mongo/Mongoose/denna fråga.)
Jag kommer att lämna denna fråga obesvarad ett tag och se om någon kan belysa ett bättre sätt att isolera den relevanta koden och felsöka det här problemet. I vårt fall var detta ett mycket systemiskt problem och MYCKET utmanande att felsöka för vår kompetensnivå vid den tiden.