En sak som kommer att tänka på här är att du kanske inte behöver göra allt det arbete du tror att du behöver, och ditt problem kan förmodligen lösas med lite hjälp från TTL-index och eventuellt begränsade samlingar . Tänk på följande poster:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Så det finns två poster och du fick det _id värde tillbaka när du infogade. Så i början hade "A" ingen att spela mot, men posten för "B" kommer att spela mot den före den.
ObejctId:s är monotona , vilket betyder att "nästa" med är alltid högre i värde från sist. Så med infogade data gör du bara så här:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
Det ger det föregående infogade "flyttet" till det aktuella draget som just gjordes, och gör detta eftersom vad som helst som tidigare infogades kommer att ha ett _id med mindre värde än den aktuella artikeln. Du ser också till att du inte "spelar" mot användarens eget drag, och naturligtvis begränsar du resultatet till endast ett dokument.
Så "flyttningarna" kommer för alltid att gå framåt. När nästa infogning görs av användare "C" får de "flytt" från användare "B", och sedan skulle användare "A" få "flytt" från användare "C ", och så vidare.
Allt som "kunde" hända här är att "B" gör nästa "flytta" i följd, och du skulle plocka upp samma dokument som i den senaste begäran. Men det är en poäng för din "session"-design, för att lagra det senaste "resultatet" och se till att du inte fick tillbaka samma sak, och som sådan, hantera det hur du än vill. vill i din design.
Det borde räcka att "leka" med. Men låt oss komma till din "radering " del.
Naturligtvis "tror" du att du vill radera saker, men tillbaka till mina första "hjälpare" borde detta inte vara nödvändigt. Ovanifrån blir radering bara en faktor för "städning", så din samling växer inte till stora proportioner.
Om du använde ett TTL-index, på ungefär samma sätt som denna handledning förklarar kommer dina samlingsposter att rensas upp åt dig och tas bort efter en viss tid.
Även vad som kan göras, och speciellt med tanke på att vi använder ökning typ av _id och att detta är mer eller mindre en "kö" till sin natur, kan du möjligen tillämpa detta som en begränsad samling
. Så du kan ställa in en maximal storlek på hur många "drag" du ska behålla vid varje given tidpunkt.
Kombinerar du de två tillsammans får du något som bara "växer" till en viss storlek, och som automatiskt städas åt dig, om aktiviteten avtar lite. Och det kommer att hålla alla operationer snabba .
Slutsatsen är att samtidigheten av "raderar " som du var orolig för har tagits bort genom att "ta bort" behovet av att ta bort dokumenten som just spelades upp. Frågan gör det enkelt, och TTL-indexet och den begränsade samlingen tar hand om din datahantering åt dig.
Så där har du vad jag tycker om ett mycket samtidigt spel "Blind War".