node.js est-il adapté au développement backend de jeux ? _node.js

Comment le serveur du site Web et le serveur de jeu sont-ils connectés ?

1. Il existe de nombreux types de jeux. Jetons d’abord un coup d’œil aux MMORPG.

Aussi simple soit-il, un serveur RPG ne peut éviter de gérer des interactions entre plusieurs personnes dans la même scène, chaque client doit recevoir des informations sur les opérations de tous les autres.

Deuxièmement, les opérations des utilisateurs sont très fréquentes et les serveurs généraux ont tendance à maintenir de longues connexions. De plus, ces liens interagissent fréquemment et il n'existe pas de stratégie de partitionnement persistante évidente, ce qui limite l'expansion horizontale du serveur. Le même scénario ne peut souvent être exécuté que sur une seule machine physique.

Troisièmement, les jeux clients n'osent généralement pas effectuer d'opérations logiques sur le client. Il est très courant que les utilisateurs le déchiffrent pour vous en quelques minutes, changent des pièces d'or et achètent deux pièces d'équipement. Par conséquent, ce serveur de carte doit vérifier les opérations de tous les joueurs sur la carte et calculer une série de logiques métier telles que l'IA des monstres et le taux d'abandon.

Nous pouvons constater qu'il existe des différences évidentes entre les serveurs de jeux traditionnels et les serveurs Web, avec des exigences commerciales uniques telles que des connexions longues, la multidiffusion, une logique métier complexe et des stratégies de partitionnement limitées.

2. Jetons un coup d'œil aux avantages de la concurrence pour les serveurs de jeux.

La concurrence est en fait un processus logique de programme et elle ne nécessite pas de support physique multicœur. Le sens général est de donner l’impression que plusieurs flux logiques indépendants s’exécutent en même temps. La concurrence au niveau du système d’exploitation est le modèle multi-processus multi-thread. Laissez le système d'exploitation gérer les interruptions d'horloge, le blocage des E/S et d'autres problèmes.

Pour le serveur, si la tâche passe la plupart de son temps sur io, le mécanisme de concurrence peut empêcher l'intégralité du service de carte d'être bloqué par l'accès io. Lorsqu'une tâche est bloquée, allouez des ressources informatiques disponibles à d'autres tâches. Dans ce cas, la simultanéité est bénéfique pour l’efficacité du serveur et le temps de réponse.

Pour les programmeurs, un flux logique indépendant signifie qu'ils peuvent effectuer leurs tâches dans un contexte fiable, simple et faiblement couplé.

Étant donné que la commutation logique du gestionnaire du système d'exploitation doit tomber à plusieurs reprises dans le noyau, certaines personnes pensent que cela est trop lent, elles créent donc des threads dans l'espace utilisateur et contrôlent plusieurs flux logiques au sein du processus. En raison des limitations des capacités de description du langage, il est trop difficile d'écrire et d'utiliser de telles choses en C/C. En conséquence, le sucre syntaxique coroutine en Erlang, Go et Lua est né.

Node.js contrôle essentiellement plusieurs flux logiques par lui-même, mais ce flux logique est distribué en fonction du statut et de la priorité des io. Dans l'implémentation actuelle, il essaie d'utiliser des io asynchrones non bloquants. Lorsqu'une seule tâche appelle io, je l'arrête et lorsque le signal d'achèvement io est envoyé, je la redémarre.

Notez ceci : chaque fois que j'exécute une tâche, je ne basculerai pas activement vers d'autres flux de programme jusqu'à ce qu'elle soit terminée ou qu'un appel io se produise. Ainsi, si cette tâche implique trop de calculs, tout le processus de cartographie sera ici bloqué.

Étant donné que node.js est asynchrone, vous devez constamment écrire des rappels pour surveiller le signal d'achèvement io. Le flux logique d'une seule tâche sera interrompu plusieurs fois. Lorsque la tâche devient assez complexe, il y a ce qu'on appelle l'enfer callbak, qui posera de gros problèmes au débogage et au développement.

3. Pour les raisons ci-dessus, je ne recommande pas d'utiliser node.js dans le développement de serveurs MMORPG non prototypes.

4. Les serveurs de jeux mobiles récemment apparus sont tout à fait adaptés à node.js, car les jeux mobiles sont limités aux problèmes de réseau Le serveur ne peut vérifier que les données clés et ne peut pas gérer les interactions entre plusieurs personnes. . Le côté serveur a été simplifié au point qu'il n'est pas différent d'un serveur Web, et la logique métier est également simple, il suffit de traiter les données puis de les conserver.