Introduction rapide au partage des principes du moteur Swoole

Au cours des six derniers mois, j'ai réalisé un projet de serveur de jeu utilisant les piles technologiques PHP et Java. Étant donné que le projet comporte des requêtes réseau à haute fréquence, la pile technologique PHP a essayé d'utiliser le moteur Swoole (un moteur de communication réseau parallèle asynchrone basé sur des événements hautes performances) pour mener à bien une partie de l'activité du jeu.

Recommandé (gratuit) : swoole

Installation de Swoole

L'installation de swoole est très simple, Puisqu’il s’agit d’un projet réalisé par des Chinois, les réponses à de nombreuses questions peuvent être trouvées dans les documents du site officiel. Il existe deux types d'installation :

• Compiler et installer. Accédez directement à github ou gitee pour télécharger la version officielle. Après la compilation et l'installation, écrivez l'extension so dans le fichier php.ini.
• Installation de conteneurs. Le moteur swoole est largement utilisé, il existe donc de nombreux conteneurs disponibles sur le hub. Sélectionnez simplement celui dont vous avez besoin et tirez-le.

Utilisez simplement Baidu pour des instructions spécifiques. Il existe de nombreux contenus connexes en ligne.

Avantages du moteur Swoole

1. Mémoire résidente. Dans les frameworks PHP traditionnels ou les fichiers uniques, avant de traiter chaque requête, les opérations de chargement du fichier de framework et de configuration doivent être effectuées. Une fois la requête terminée, toutes les ressources et la mémoire seront libérées, il n'y a donc pas lieu de s'inquiéter des fuites de mémoire. . Cependant, si le nombre de requêtes augmente et que la concurrence est élevée, les ressources sont créées rapidement et libérées immédiatement, ce qui entraînera une forte baisse de l'efficacité opérationnelle du programme PHP. L'utilisation de Swoole ne pose pas ce problème : une fois le code PHP chargé dans la mémoire, son cycle de vie est plus long, donc la connexion à la base de données et les autres objets volumineux ainsi établis ne seront pas libérés. Chaque requête ne doit traiter qu'une petite quantité de code, et ce code est uniquement compilé par l'analyseur PHP et réside en mémoire lors de sa première exécution. À l'avenir, OPCODE sera chargé directement pour permettre au moteur Zend de fonctionner directement. De plus, des éléments que PHP ne pouvait pas implémenter auparavant, tels que le pool de connexions à la base de données et le pool de connexions au cache, peuvent être implémentés sous le moteur Swoole. L'efficacité opérationnelle du système sera grandement améliorée.
2. Développement rapide. Le moteur Swoole fournit un serveur multithread asynchrone en langage PHP, un client réseau TCP/UDP asynchrone, MySQL asynchrone, Redis asynchrone, un pool de connexions à la base de données, AsyncTask, une file d'attente de messages, une minuterie en millisecondes, une lecture et une écriture de fichiers asynchrones et une requête DNS asynchrone. Swoole a un serveur/client Http/WebSocket intégré et un serveur Http2.0.
3. Mode de programmation Coroutine. Swoole4 peut implémenter des programmes asynchrones en utilisant du code entièrement synchrone. Il n'est pas nécessaire d'ajouter des mots-clés supplémentaires au code PHP. La couche inférieure effectue automatiquement la planification des coroutines pour implémenter les E/S asynchrones.

Analyse du processus du moteur Swoole

L'organigramme du fonctionnement de Swoole est le suivant :

Le fil ou processus dans Swoole

Le schéma de structure est le suivant :

Le moteur Swoole est divisé en deux modes : le mode monothread et le mode processus. Cet article traite uniquement du mode processus. Les différences spécifiques entre les deux sont expliquées dans la documentation officielle.

Le processus principal

est utilisé pour gérer les événements principaux de Swoole, tels que les connexions des clients et les canaux de communication locaux. Il existe plusieurs threads dans le processus maître et chaque thread exécute une instance de la fonction epol. (Puisque le processus Worker n'est pas dérivé par le processus Master, le processus Worker peut toujours exister après avoir tué de force le processus Master)

Thread Reactor

Le processus principal de Swoole est un multi-thread programme. Il existe un groupe de threads très important appelés threads Reactor. C'est le thread qui gère réellement les connexions TCP et envoie et reçoit des données.
Après avoir accepté une nouvelle connexion, le thread principal de Swoole attribuera la connexion à un thread Reactor fixe, et ce thread sera chargé de surveiller le socket. Lisez les données lorsque le socket est lisible, effectuez une analyse de protocole et envoyez la demande au processus Worker. Envoyer des données au client TCP lorsque le socket est accessible en écriture

Processus Manager

Les processus de travail/tâche dans swoole sont tous dupliqués et gérés par le processus Manager.
Lorsque le processus enfant se termine, le processus gestionnaire est chargé de recycler le processus enfant pour éviter de devenir un processus zombie. Et créez de nouveaux processus enfants
Lorsque le serveur est arrêté, le processus gestionnaire enverra des signaux à tous les processus enfants pour avertir les processus enfants de fermer le service
Lorsque le serveur est rechargé, le processus gestionnaire se fermera/redémarrera l'enfant traite un par un

Processus de travail

Swoole fournit un mécanisme complet de gestion des processus lorsque le processus de travail se termine anormalement, comme une erreur fatale dans PHP, étant accidentellement tué par d'autres programmes, ou quitter normalement après avoir atteint le nombre de fois max_request. Le processus principal redémarrera le nouveau processus Worker. Le code peut être écrit dans le processus Worker comme Apache+php ou php-fpm ordinaire. Il n'est pas nécessaire d'écrire du code de rappel asynchrone comme Node.js.

Fonction de rappel de chaque processus

Fonction de rappel dans Master :

• onStart
• onShutdown

Fonction de rappel dans le processus Worker

• onWorkerStart
• onWorkerStop
• onConnect
• onClose
• onReceive
• onFinish

Fonction de rappel dans le processus TaskWorker

• onTask
• onWorkerStart

Fonction de rappel dans le processus Manager

• onManagerStart
• onManagerStop

La relation entre Reactor, Worker et TaskWorker

peut être comprise car Reactor est nginx et Worker est php-fpm. Le thread Reactor traite les requêtes réseau de manière asynchrone et en parallèle, puis les transmet au processus Worker pour traitement. Reactor et Worker communiquent via UnixSocket.
Dans les applications php-fpm, une tâche est souvent livrée de manière asynchrone à une file d'attente telle que Redis, et certains processus PHP sont démarrés en arrière-plan pour traiter ces tâches de manière asynchrone. TaskWorker fourni par Swoole est une solution plus complète qui intègre la gestion des processus de livraison des tâches, de file d'attente et de traitement des tâches PHP. Le traitement des tâches asynchrones peut être implémenté très simplement grâce à l'API fournie par la couche sous-jacente. De plus, TaskWorker peut également renvoyer un résultat au Worker une fois l'exécution de la tâche terminée.
Reactor, Worker et TaskWorker de Swoole peuvent être étroitement intégrés pour fournir des méthodes d'utilisation plus avancées. Une métaphore plus populaire : supposons que le serveur d'applications Swoole est une usine et que le Reactor est un service de vente, acceptant les commandes des clients. Le travailleur est le travailleur. Lorsque le vendeur reçoit la commande, le travailleur se met au travail pour produire ce que le client veut. Le TaskWorker peut être compris comme un personnel administratif, qui peut aider le travailleur à effectuer certaines tâches afin qu'il puisse se concentrer sur son travail.
La couche inférieure attribuera un identifiant unique au processus Worker et au processus TaskWorker. Différents processus Worker et TaskWorker peuvent communiquer via l'interface sendMessage.

La division du travail de chaque fil de processus dans le projet réel :

• Manager de processus : responsable de la gestion des processus de travail, de la création ou du recyclage
• Processus de travail : traitement de la logique du jeu
• processus taskWorker : envoi de paquets réseau au client, fermeture des connexions TCP inactives à long terme

Compatibilité des versions Swoole

La version du moteur swoole utilisée dans la phase de développement de ce projet était la 1.9.6. Plus tard, parce que l'environnement de test a été installé sur la version 4.3.2, nous avons essayé d'ajuster le code métier. Cependant, la rétrocompatibilité de swoole est très admirable. Dans ce processus, un seul problème d'incompatibilité de code a été découvert : un paramètre de configuration lié à swoole_server. Dans la version originale, il était configuré à l'aide de nombres diaboliques, mais dans la nouvelle version, celui-ci. le numéro n'était pas défini par macro. Plus tard, j'ai trouvé le groupe de définition de macro en regardant le code source de swoole, puis j'ai modifié cette configuration. (Cependant, la mise à niveau fluide de la version est également basée sur relativement peu de codes swoole business, elle est donc à titre de référence uniquement

Plus de recommandations d'apprentissage connexes : tutoriel swoole

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!