Per verzoek is hier een overzicht van ons probleem en hoe we het hebben opgelost:
In ons systeem hebben we een aangepaste documentvergrendelingsroutine gemaakt (met behulp van redis-lock), waarbij het volgende gebeurde in deze precieze (onjuiste) volgorde:
ONJUISTE VOLGORDE VAN BEWERKINGEN:
- Klantverzoek ontvangen
- Document vergrendeld
- Document opgehaald
- Document bewerkt
- Document ontgrendeld
- Klantverzoek opgelost
- Document opgeslagen
Zodra je het uitgeschreven ziet, is het probleem duidelijk:we waren onze documenten aan het opslaan buiten onze documentvergrendeling.
Laten we aannemen dat #6 100 ms duurt in ons systeem. Dat is een venster van 100 ms waarin als andere verzoeken hetzelfde document pakken, we een opslagconflict krijgen (de titelfout in deze vraag is in feite een opslagconflict IMHO).
Met andere woorden/voorbeeld:in ons systeem pakte Request A versie 1 van Document X, bewerkte het en ontgrendelde het, maar voordat Request A het document opsloeg, pakte Request B Document X en verhoogde het naar versie 2 (lees verder op Mongo versies voor meer info hierover). Vervolgens lost Request A zijn clientverzoek op en gaat document X opslaan, maar het probeert versie 1 op te slaan en ziet nu dat het versie 2 heeft, en dus de bovenstaande fout.
Dus de oplossing is eenvoudig. Bewaar uw documenten in uw slot. (Verplaats in het bovenstaande voorbeeld #7 naar vóór #5. Zie hieronder.)
CORRECTE/VASTE VOLGORDE VAN BEWERKINGEN
- Klantverzoek ontvangen
- Document vergrendeld
- Document opgehaald
- Document bewerkt
- Document opgeslagen
- Document ontgrendeld
- Klantverzoek opgelost
(Je zou kunnen argumenteren dat #6 en #7 verwisseld moeten worden, maar dat valt buiten het bestek van Mongo/Mongoose/deze vraag.)
Ik laat deze vraag een tijdje onbeantwoord en kijk of iemand enig licht kan werpen op een betere manier om de relevante code te isoleren en dit probleem op te lossen. In ons geval was dit een zeer systemisch probleem en ZEER uitdagend om op te lossen voor ons vaardigheidsniveau op dat moment.