In node.js wird tatsächlich nur eine Anfrage gleichzeitig ausgeführt (der Javascript-Interpreter ist Single-Threaded), bis Sie im nativen Code auf eine Art asynchrone Operation treffen und dann eine andere Anfrage ausgeführt wird, während die andere auf I/O wartet . Wenn es eine begrenzte Ressource gibt, hinter der alle Anfragen her sind, ist es nur ein Rennen, um zu sehen, welche Anfrage weit genug durch Ihren Code kommt, um die Ressource zu erhalten. Wenn Sie Ihren Server für zusätzliche Skalierbarkeit gruppieren, führt jeder Cluster einen Javascript-Thread aus.
Wenn Sie jede eingehende Anfrage in einer Warteschlange warten lassen, bis alle anderen Anfragen, die davor kamen, vollständig erledigt sind (etwas, das getan werden könnte), würden Sie die Skalierbarkeit Ihres node.js-Servers ernsthaft ruinieren, und dies würde die meiste Zeit der Fall sein untätig herumsitzen und darauf warten, dass eine I/O-Operation ausgeführt wird, daher scheint es unwahrscheinlich, dass dies das richtige Design ist.
Das übliche Schema besteht hier darin, einfach die erste Anforderung zuzulassen, die die Ressource beansprucht (auch wenn möglicherweise mehrere Ressourcen gleichzeitig ausgeführt werden). Ob dies immer die Anfrage ist, die zuerst auf Ihrem Server angekommen ist oder nicht, wird nicht bekannt sein, aber es wird naheliegend sein, und die Benutzergemeinschaft wird wahrscheinlich nicht wissen, ob sie nur aufgrund der Varianz in ein paar Millisekunden daneben lag Verarbeitungsgeschwindigkeit von zwei Anfragen.
Sie müssen sicherstellen, dass Ihr Code, der auf gemeinsam genutzte Ressourcen (wie Datenbanken) zugreift, sicher für Parallelität ist und keine störenden Annahmen über gemeinsam genutzte Daten trifft.
