Comment maximiser la capacité de concurrence du serveur PHP avec des ressources limitées

Supposons que l'application utilise 5W RMB pour acheter auprès des fournisseurs. Le jour de l'inscription, un grand nombre de candidats affluent et le nombre de demandes simultanées grimpe à . 30W+, provoquant l'arrêt du système, le refus du service et les souffrances des candidats. Impossible de s'inscrire, 5W RMB peuvent-ils prendre en charge la simultanéité 30W+ ?

Mais pour nous, autant soulever le problème sous un autre angle : "Comment maximiser la capacité de concurrence du serveur avec des ressources limitées." Supposons que vous soyez un leader technique, comment concevriez-vous et structureriez-vous un projet avec un grand nombre de concurrence ?

Tout d'abord, nous pouvons donner une idée générale de​​ce projet. D'après la description ci-dessus, il n'est pas difficile de voir que le goulot d'étranglement de ce projet est « l'écriture simultanée » plutôt que la « lecture ». ", donc du point de vue de l'allocation des ressources, nous pouvons incliner " "Écrire", ici j'écris toutes les données dans Redis. De plus, nous devons également faire de notre mieux pour migrer les opérations de lecture MySQL vers Redis. Le travail effectué par MySQL est plus enclin à certaines opérations de lecture et d'écriture non simultanées conventionnelles.

Serveur

Lorsqu'un utilisateur le demande, l'équilibreur de charge le charge sur chaque serveur

Il s'agit d'un test de stress data de symfony, utilisant la configuration de 1 CPU, 4 Go et PHP 7.

Les données dans l'image ci-dessus proviennent du site officiel de swoole. Après avoir ajouté l'exécution de notre logique métier réelle, nous pouvons constater que lorsque nous utilisons la méthode de démarrage de la mémoire résidente. , 3 serveurs bas de gamme peuvent résoudre le problème ci-dessus qui nécessite 16 serveurs.

Base de données

En fait, beaucoup de gens comprendront qu'après une certaine période de contact avec le backend, le goulot d'étranglement de nombreux projets Internet aujourd'hui est plus concentré dans la base de données I /O Dans ce domaine, il n'y a pas d'écart particulièrement important entre les différentes langues. Y compris la méthode de démarrage PHP-FPM largement critiquée, vous pouvez également utiliser swoole et d'autres méthodes pour la remplacer. Par conséquent, dans ce projet, nous nous concentrerons davantage sur la base de données, et nous pouvons essayer d'utiliser Redis pour le résoudre. Bien sûr, dans le code spécifique, nous devons également préparer un certain nombre de pools de connexions de données à l'avance. De plus, on considère également que bien que la vitesse d'écriture de MongoDB soit beaucoup plus rapide que celle de MySQL dans la même configuration, il présente toujours des défauts évidents par rapport à Redis.

Inscription et connexion

L'inscription et la connexion doivent en fait être divisées en deux parties, qui correspondent respectivement à "écrire" et "lire". Dans le cas d'une lecture et d'une écriture simultanées élevées, l'utilisation directe de MySQL explosera comme vous l'espériez. Par conséquent, nous pouvons mettre en cache les données utilisateur dans Redis pendant le processus de création de l'ensemble du projet. Problème « d'écriture » : lorsque le nombre d'utilisateurs n'est pas clair et que le degré de concurrence est important, je préfère ne pas stocker les données utilisateur directement dans la base de données. Nous pouvons concevoir un commutateur ou un seuil pour définir la méthode d'entreposage de l'utilisateur. Lorsque la concurrence est importante, les utilisateurs peuvent stocker de manière asynchrone via MQ, mais en temps normal, les utilisateurs peuvent stocker normalement.

Formulaire de soumission

Parce que ce projet ne fait pas partie de nos ventes flash courantes et nécessite une notification immédiate, la conception de notre projet a considérablement réduit la difficulté. La fonction de soumission du formulaire est similaire à celle de l'inscription. Nous pouvons charger complètement les données dans la base de données de manière asynchrone, puis les examiner en arrière-plan.

Résumé

Je n'entrerai pas dans les détails sur la question de savoir si d'autres CDN et MySQL nécessitent un maître-esclave, cela dépend de la situation réelle. Théoriquement, si vous utilisez PHP-FPM, cela coûtera environ 19 000 yuans/mois pour résoudre ce problème du projet. Lors de l'utilisation de swoole, cela coûtera environ 4 500 yuans/mois. Je ne préconise pas swoole ici. c'est que lorsque nous sommes confrontés à de grands projets simultanés, en particulier lorsque la logique métier est relativement complexe, nous pouvons mieux résoudre le problème en utilisant la mémoire résidente, et cela n'a rien à voir avec le langage. Enfin, il convient de noter que ce qui précède n’est qu’une étape théorique et que les données réelles nécessitent des tests plus approfondis. Le contenu de l'article provient d'Internet. S'il y a une écriture incorrecte, veuillez le signaler.

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!