Introduction aux scénarios d'application
Connectez-vous et communiquez avec des périphériques matériels (dispositifs de positionnement)
Système de messagerie instantanée (utilisé pour le direct pages de diffusion Communication par chat) (Apprentissage recommandé : tutoriel vidéo swoole )
Scénario 1 - Collecte en temps réel de données de positionnement et sortie en temps réel (par exemple, conduite du conducteur Didi trajectoire)
Instructions :
Il est nécessaire de recevoir tous les appareils de positionnement en temps réel et d'afficher les relevés de tracé en temps réel sur la carte
Remarque :
Le premier point :
Utilisateurs 1, 2, 3 connectés au serveur web1 Lorsque web1 diffuse des informations, il ne peut diffuser que les utilisateurs 1, 2, 3, mais pas les utilisateurs connectés web2 4, 5, 6. Supposons que la scène discute. Seuls les utilisateurs du serveur web1 peuvent le voir. Le serveur web2 ne peut pas le recevoir.
Deuxième point : Contrôle de la fréquence des messages, par exemple : 100 appareils, 100 utilisateurs, 100 appareils téléchargent une donnée par seconde, ce qui nécessite à diffuser à chaque utilisateur en temps réel, soit 100*100 = 1 W fois par seconde, afin de pouvoir résumer les données diffusées par seconde à tous les utilisateurs et autres méthodes
Scénario 2 - Uniquement collecter les appareils de positionnement et les stocker dans la base de données
Instructions : Les données téléchargées par tous les appareils de positionnement doivent être saisies dans la bibliothèque, 7 appareils, une donnée par seconde, j'utilise personnellement la fonction de tâche de swoole ( délivrer une tâche asynchrone au pool task_worker, cette fonction est non bloquante, le nombre de processus de travail peut également être configuré) puis appeler l'interface pour entrer dans la bibliothèque
Problème d'alarme mémoire du serveur
Raison : cela réside dans la fonction swoole_server->task
Officiellement introduit, la couche inférieure de la tâche utilise la communication par canal Unix Socket, qui est une mémoire pleine, pas de consommation d'E/S. Les performances de lecture et d'écriture d'un seul processus peuvent atteindre 1 million/s. Différents processus utilisent différents pipelines pour communiquer, ce qui peut maximiser l'utilisation de plusieurs cœurs.
Mais si la tâche consiste à appeler l'interface du programme, en raison du retard du réseau, lorsque les tâches ajoutées sont plus volumineuses que les tâches consommées, l'utilisation de la mémoire continuera d'augmenter, provoquant une saturation de la mémoire du serveur.
Solution : Contrôlez la fréquence des messages entrant dans la tâche. Vous pouvez définir cette heure et si elle peut être retardée en fonction de votre propre scénario commercial, résumer toutes les données en 1 seconde, puis appeler l'interface du programme (je utiliser personnellement Redis pour résumer : wiki du framework swoole
Avantages
encapsule la classe modèle de la base de données, l'interface ORM de la base de données
encapsulation redis , peut obtenir un accès multi-instance
Le framework a certaines méthodes couramment utilisées, telles que le journal, etc. (je n'ai utilisé que le journal)Webim a un démon officiel, vous pouvez vous y référer
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!