En node.js, solo se ejecuta una solicitud a la vez (el intérprete de Javascript es de un solo subproceso) hasta que se ejecuta algún tipo de operación asíncrona en código nativo y luego otra solicitud comienza a ejecutarse mientras la otra espera E/S. . Si hay algún recurso limitado que buscan todas las solicitudes, es solo una carrera para ver qué solicitud llega lo suficientemente lejos a través de su código para obtener el recurso. Si agrupa su servidor para mayor escalabilidad, entonces cada clúster ejecuta un subproceso de Javascript.
Si hiciera que cada solicitud entrante esperara en una cola hasta que todas las demás solicitudes anteriores estuvieran completas (algo que podría hacerse), entonces arruinaría seriamente la escalabilidad de su servidor node.js y la mayoría de las veces lo haría. estar inactivo esperando que se realice alguna operación de E/S, por lo que parece poco probable que ese sea el diseño correcto.
El esquema habitual aquí es simplemente dejar que la primera solicitud que pasa para reclamar el recurso lo tenga (aunque varios recursos pueden estar ejecutándose al mismo tiempo). No se sabrá si esta es siempre la solicitud que llegó por primera vez a su servidor o no, pero estará cerca y es poco probable que la comunidad de usuarios sepa si se desvió por unos pocos milisegundos solo debido a la variación en velocidad de procesamiento de dos solicitudes.
Deberá asegurarse de que el código que accede a los recursos compartidos (como las bases de datos) sea seguro para la concurrencia y no haga suposiciones problemáticas sobre los datos compartidos.
