Una cosa que me viene a la mente aquí es que es posible que no necesite hacer todo el trabajo que cree que debe hacer, y su problema probablemente se pueda resolver con un poco de ayuda de Índices TTL y posiblemente colecciones limitadas . Considere las siguientes entradas:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Así que hay dos entradas y obtuviste ese _id valor de vuelta cuando insertaste. Entonces, al principio, "A" no tenía a nadie contra quien jugar, pero la entrada de "B" jugará contra la anterior.
Los ObejctId son monotonic , lo que significa que el "siguiente" es siempre mayor en valor que el anterior. Entonces, con los datos insertados, solo haz esto:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
Eso le da el "movimiento" insertado anterior al movimiento actual que se acaba de hacer, y hace esto porque cualquier cosa que se insertó previamente tendrá un _id con menor valor que el elemento actual. También te aseguras de que no estás "jugando" contra el propio movimiento del usuario y, por supuesto, limitas el resultado a un solo documento.
Por lo tanto, los "movimientos" siempre avanzarán. Cuando el usuario "C" realice la siguiente inserción, obtendrán el "movimiento" del usuario "B", y luego el usuario "A" obtendrá el "movimiento" del usuario "C". ", y así sucesivamente.
Todo lo que "podría" pasar aquí es que "B" haga el siguiente "mover" en secuencia, y recogería el mismo documento que en la última solicitud. Pero ese es un punto para tu diseño de "sesión", para almacenar el último "resultado" y asegurarse de que no recibiste lo mismo, y como tal, trata eso como tú desea en su diseño.
Eso debería ser suficiente para "jugar". Pero vayamos a tu "eliminación " parte.
Naturalmente, "piensas" que quieres eliminar cosas, pero volviendo a mis "ayudantes" iniciales, esto no debería ser necesario. Desde arriba, la eliminación se convierte solo en un factor de "limpieza", por lo que su colección no crece en proporciones masivas.
Si aplicó un índice TTL, de la misma manera que este tutorial explica, las entradas de su colección se limpiarán por usted y se eliminarán después de un cierto período de tiempo.
También lo que se puede hacer, y sobre todo teniendo en cuenta que estamos usando el aumento naturaleza del _id clave y que esto es más o menos una "cola" en la naturaleza, posiblemente podría aplicar esto como un colección limitada
. Por lo tanto, puede establecer un tamaño máximo para la cantidad de "movimientos" que mantendrá en cualquier momento.
Al combinar los dos, obtienes algo que solo "crece" hasta cierto tamaño, y se limpiará automáticamente si la actividad se ralentiza un poco. Y eso mantendrá todas las operaciones rápidas. .
La conclusión es que la concurrencia de "elimina " que le preocupaba se eliminó "eliminando" la necesidad de eliminar los documentos que se acababan de reproducir. La consulta lo mantiene simple, y el índice TTL y la colección limitada se encargan de la administración de datos por usted.
Ahí tienes mi opinión sobre un juego muy simultáneo de "Blind War".
