L'indicateur que nous mesurons habituellement le débit d'un système Web est le QPS (Query Per Second, nombre de requêtes traitées par seconde). Cet indicateur est très critique pour résoudre des scénarios de forte concurrence de plusieurs dizaines de milliers de fois par seconde. Par exemple, nous supposons que le temps de réponse moyen pour traiter une demande commerciale est de 100 ms. Dans le même temps, il y a 20 serveurs Web Apache dans le système et MaxClients est configuré sur 500 (indiquant le nombre maximum de connexions Apache).
Ensuite, le QPS maximal théorique de notre système Web est (méthode de calcul idéalisée) :
20*500/0,1 = 100000 (100 000 QPS)
咦 ? Notre système semble très puissant. Il peut traiter 100 000 demandes en une seconde. La vente flash de 5 W/S semble être un « tigre de papier ». La situation actuelle n’est bien sûr pas si idéale. Dans les scénarios réels à forte concurrence, les machines sont soumises à une charge élevée et le temps de réponse moyen sera alors considérablement augmenté.
Un serveur p4 ordinaire peut prendre en charge jusqu'à environ 100 000 IP par jour. Si le nombre de visites dépasse 10 W, un serveur dédié est nécessaire pour le résoudre. Si le matériel n'est pas puissant, quel que soit le logiciel. optimisé, cela ne servira à rien. Les principaux facteurs qui affectent la vitesse du serveur
sont : le réseau - la vitesse de lecture et d'écriture du disque dur - la taille de la mémoire - la vitesse de traitement du processeur.
En ce qui concerne le serveur Web, plus Apache ouvre de processus de connexion, plus le CPU doit gérer de changements de contexte, ce qui augmente la consommation du CPU et entraîne directement une augmentation du temps de réponse moyen. Par conséquent, le nombre de MaxClients mentionné ci-dessus doit être pris en compte en fonction de facteurs matériels tels que le processeur et la mémoire. Plus n'est certainement pas meilleur. Vous pouvez le tester via le propre abench d'Apache et obtenir une valeur appropriée. Ensuite, nous choisissons Redis pour le stockage au niveau du fonctionnement de la mémoire. Dans un état de forte concurrence, le temps de réponse du stockage est crucial. Bien que la bande passante du réseau soit également un facteur, ces paquets de requêtes sont généralement relativement petits et deviennent rarement un goulot d'étranglement pour les requêtes. Il est rare que l’équilibrage de charge devienne un goulot d’étranglement du système, nous n’en discuterons donc pas ici.
Alors la question est, en supposant que notre système, dans un état de concurrence élevée de 5w/s, le temps de réponse moyen passe de 100ms à 250ms (situation réelle, encore plus) :
20 *500/0,25 = 40 000 (40 000 QPS)
Notre système se retrouve donc avec 40 000 QPS Face à 50 000 requêtes par seconde, il y a une différence de 10 000.
Par exemple, à une intersection d'autoroute, 5 voitures viennent et dépassent 5 voitures par seconde, et l'intersection d'autoroute fonctionne normalement. Du coup, seules 4 voitures peuvent traverser cette intersection en une seconde, et la circulation est toujours la même. Du coup, il y aura forcément un embouteillage. (On a l'impression que 5 voies se sont soudainement transformées en 4 voies)
De même, en une certaine seconde, 20*500 processus de connexion disponibles fonctionnent à pleine capacité, mais il y a encore 10 000 nouvelles demandes, il n'y a pas de connexion. processus disponible, et il est prévu que le système tombe dans un état anormal.
En fait, dans des scénarios commerciaux normaux sans forte concurrence, des situations similaires se produisent. Il y a un problème avec une certaine interface de demande commerciale et le temps de réponse est extrêmement lent. .L'ensemble de la requête Web Le temps de réponse est très long, remplissant progressivement le nombre de connexions disponibles sur le serveur Web, et aucun processus de connexion n'est disponible pour les autres requêtes commerciales normales.
Le problème le plus terrifiant concerne les caractéristiques comportementales des utilisateurs. Plus le système est indisponible, plus les utilisateurs cliquent fréquemment, le cercle vicieux conduit finalement à une « avalanche » (l'une des machines Web raccroche, provoquant un blocage). le trafic à disperser sur Sur d'autres machines qui fonctionnent normalement, les machines normales se bloqueront également, et alors un cercle vicieux se produira), faisant tomber l'ensemble du système Web.
3. Redémarrage et protection contre les surcharges
Si une "avalanche" se produit dans le système, un redémarrage imprudent du service ne résoudra pas le problème. Le phénomène le plus courant est qu'après le démarrage, il raccroche immédiatement. À ce stade, il est préférable de refuser le trafic au niveau de la couche d’entrée, puis de redémarrer. Si des services comme redis/memcache sont également en panne, vous devez faire attention au « préchauffage » lors du redémarrage, et cela peut prendre beaucoup de temps.
Dans les scénarios de vente flash et de vente urgente, le trafic dépasse souvent la préparation et l'imagination de notre système. À ce stade, une protection contre les surcharges est nécessaire. Le refus des demandes constitue également une mesure de protection si une condition de charge complète du système est détectée. Mettre en place un filtrage sur le front-end est le moyen le plus simple, mais cette approche est un comportement « critiqué » par les utilisateurs. Ce qui est plus approprié est de définir une protection contre les surcharges au niveau de la couche d'entrée CGI pour renvoyer rapidement les demandes directes des clients
Sécurité des données sous haute concurrence
Nous savons que lorsque plusieurs threads écrivent dans le même fichier ( Plusieurs threads exécutent le même morceau de code en même temps. Si le résultat de chaque exécution est le même que celui d'une exécution à un seul thread et que le résultat est le même que celui attendu, il est thread-safe). S'il s'agit d'une base de données MySQL, vous pouvez utiliser son propre mécanisme de verrouillage pour résoudre le problème. Cependant, dans les scénarios de concurrence à grande échelle, MySQL n'est pas recommandé. Il existe un autre problème dans les scénarios de vente flash et de vente urgente, à savoir le « envoi excessif ». Si cet aspect n'est pas soigneusement contrôlé, un envoi excessif se produira. Nous avons également entendu dire que certaines sociétés de commerce électronique mènent des activités d'achat précipitées. Une fois que l'acheteur a réussi à prendre la photo, le commerçant ne reconnaît pas la commande comme valide et refuse de livrer la marchandise. Le problème ici n’est peut-être pas nécessairement que le commerçant est traître, mais qu’il est causé par le risque de surémission au niveau technique du système.
1. Raisons de la livraison excessive
Supposons que dans un certain scénario d'achat précipité, nous n'ayons que 100 produits au total, au dernier moment, nous avons consommé 99 produits et il ne reste que le dernier. À ce moment-là, le système a envoyé plusieurs demandes simultanées. Les soldes de produits lus par ces demandes étaient tous de 99, puis ils ont tous rendu ce jugement de solde, ce qui a finalement conduit à une émission excessive. (Identique à la scène mentionnée plus tôt dans l'article)
Dans l'image ci-dessus, l'utilisateur simultané B a également "acheté avec succès", permettant à une personne supplémentaire d'obtenir le produit. Ce scénario est très facile à réaliser dans des situations de forte concurrence.
Plan d'optimisation 1 : définissez le champ du numéro de champ d'inventaire sur non signé Lorsque l'inventaire est 0, car le champ ne peut pas être un nombre négatif, false sera renvoyé
<?php
//优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false
include('./mysql.php');
$username = 'wang'.rand(0,1000);
//生成唯一订单
function build_order_no(){
return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0,$username){
global $conn;
$sql="insert into ih_log(event,type,usernma)
values('$event','$type','$username')";
return mysqli_query($conn,$sql);
}
function insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number)
{
global $conn;
$sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price,username,number)
values('$order_sn','$user_id','$goods_id','$sku_id','$price','$username','$number')";
return mysqli_query($conn,$sql);
}
//模拟下单操作
//库存是否大于0
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' ";
$rs=mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
if($row['number']>0){//高并发下会导致超卖
if($row['number']<$number){
return insertLog('库存不够',3,$username);
}
$order_sn=build_order_no();
//库存减少
$sql="update ih_store set number=number-{$number} where sku_id='$sku_id' and number>0";
$store_rs=mysqli_query($conn,$sql);
if($store_rs){
//生成订单
insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number);
insertLog('库存减少成功',1,$username);
}else{
insertLog('库存减少失败',2,$username);
}
}else{
insertLog('库存不够',3,$username);
}
?>Copier après la connexion
2. idée de verrouillage
Il existe de nombreuses idées pour résoudre la sécurité des threads, et nous pouvons commencer la discussion dans la direction du "verrouillage pessimiste".
Verrouillage pessimiste, c'est-à-dire que lors de la modification des données, l'état verrouillé est adopté pour exclure les modifications des requêtes externes. Lorsque vous rencontrez un état verrouillé, vous devez attendre.
Bien que la solution ci-dessus résolve le problème de la sécurité des threads, n'oubliez pas que notre scénario est "à haute concurrence". En d'autres termes, il y aura de nombreuses requêtes de modification de ce type, et chaque requête devra attendre un "verrou". Certains threads n'auront peut-être jamais la chance de récupérer ce "verrou", et de telles requêtes mourront là. Dans le même temps, de nombreuses demandes de ce type apparaîtront, ce qui augmentera instantanément le temps de réponse moyen du système. En conséquence, le nombre de connexions disponibles sera épuisé et le système tombera dans une exception.
Plan d'optimisation 2 : Utiliser les transactions MySQL pour verrouiller les lignes d'opérations
<?php
//优化方案2：使用MySQL的事务，锁住操作的行
include('./mysql.php');
//生成唯一订单号
function build_order_no(){
return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0){
global $conn;
$sql="insert into ih_log(event,type)
values('$event','$type')";
mysqli_query($conn,$sql);
}
//模拟下单操作
//库存是否大于0
mysqli_query($conn,"BEGIN"); //开始事务
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' FOR UPDATE";//此时这条记录被锁住,其它事务必须等待此次事务提交后才能执行
$rs=mysqli_query($conn,$sql);
$row=$rs->fetch_assoc();
if($row['number']>0){
//生成订单
$order_sn=build_order_no();
$sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
$order_rs=mysqli_query($conn,$sql);
//库存减少
$sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
$store_rs=mysqli_query($conn,$sql);
if($store_rs){
echo '库存减少成功';
insertLog('库存减少成功');
mysqli_query($conn,"COMMIT");//事务提交即解锁
}else{
echo '库存减少失败';
insertLog('库存减少失败');
}
}else{
echo '库存不够';
insertLog('库存不够');
mysqli_query($conn,"ROLLBACK");
}
?>Copier après la connexion
3 Idée de file d'attente FIFO
D'accord, modifions légèrement ce qui précède Dans ce scénario. , nous mettons directement la requête dans la file d'attente et utilisons FIFO (First Input First Output, first in first out). Dans ce cas, nous ne ferons pas en sorte que certaines requêtes n'obtiennent jamais le verrou. En voyant cela, avez-vous l'impression de transformer de force le multi-threading en mono-threading ?
Ensuite, nous avons maintenant résolu le problème de verrouillage et toutes les demandes sont traitées dans une file d'attente « premier entré, premier sorti ». Ensuite, un nouveau problème survient. Dans un scénario à forte concurrence, parce qu'il y a de nombreuses requêtes, la mémoire de la file d'attente peut être « explosée » en un instant, et le système tombera alors dans un état anormal. Ou concevoir une énorme file d'attente de mémoire est également une solution. Cependant, la vitesse à laquelle le système traite les requêtes dans une file d'attente ne peut être comparée au nombre de requêtes qui affluent follement dans la file d'attente. En d'autres termes, de plus en plus de requêtes s'accumuleront dans la file d'attente. Finalement, le temps de réponse moyen du système Web diminuera encore considérablement et le système tombera toujours dans une exception.
4. L'idée du verrouillage de fichiers
Pour les applications où l'IP quotidienne n'est pas élevée ou le nombre de simultanéités n'est pas très grand, il n'est généralement pas nécessaire d'en tenir compte ! Il n’y a aucun problème avec les méthodes normales de manipulation de fichiers. Mais si la concurrence est élevée, lorsque nous lisons et écrivons des fichiers, il est très probable que plusieurs processus fonctionneront sur le fichier suivant. Si l'accès au fichier n'est pas exclusif à ce moment-là, cela entraînera facilement une perte de données
.
Plan d'optimisation 4 : Utiliser des verrous exclusifs de fichiers non bloquants
<?php
//优化方案4：使用非阻塞的文件排他锁
include ('./mysql.php');
//生成唯一订单号
function build_order_no(){
return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0){
global $conn;
$sql="insert into ih_log(event,type)
values('$event','$type')";
mysqli_query($conn,$sql);
}
$fp = fopen("lock.txt", "w+");
if(!flock($fp,LOCK_EX | LOCK_NB)){
echo "系统繁忙，请稍后再试";
return;
}
//下单
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id'";
$rs = mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
if($row['number']>0){//库存是否大于0
//模拟下单操作
$order_sn=build_order_no();
$sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
$order_rs = mysqli_query($conn,$sql);
//库存减少
$sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
$store_rs = mysqli_query($conn,$sql);
if($store_rs){
echo '库存减少成功';
insertLog('库存减少成功');
flock($fp,LOCK_UN);//释放锁
}else{
echo '库存减少失败';
insertLog('库存减少失败');
}
}else{
echo '库存不够';
insertLog('库存不够');
}
fclose($fp);
?>Copier après la connexion
5. Idée de verrouillage optimiste
À ce stade, nous pouvons discuter de l'idée du « verrouillage optimiste » . Le verrouillage optimiste adopte un mécanisme de verrouillage plus souple que le « verrouillage pessimiste », et la plupart d'entre eux utilisent des mises à jour de version. L'implémentation est que toutes les demandes concernant ces données peuvent être modifiées, mais un numéro de version des données sera obtenu. Seules celles avec des numéros de version cohérents pourront être mises à jour avec succès, et les autres demandes échoueront. Dans ce cas, nous n’avons pas besoin de prendre en compte le problème de la file d’attente, mais cela augmentera la charge de calcul du processeur. Cependant, dans l’ensemble, c’est une meilleure solution.
Il existe de nombreux logiciels et services qui prennent en charge la fonction de « verrouillage optimiste », comme watch dans Redis en fait partie. Avec cette implémentation, nous garantissons la sécurité des données.
Plan d'optimisation 5 : surveiller dans Redis
<?php
$redis = new redis();
$result = $redis->connect('127.0.0.1', 6379);
echo $mywatchkey = $redis->get("mywatchkey");
/*
//插入抢购数据
if($mywatchkey>0)
{
$redis->watch("mywatchkey");
//启动一个新的事务。
$redis->multi();
$redis->set("mywatchkey",$mywatchkey-1);
$result = $redis->exec();
if($result) {
$redis->hSet("watchkeylist","user_".mt_rand(1,99999),time());
$watchkeylist = $redis->hGetAll("watchkeylist");
echo "抢购成功！<br/>";
$re = $mywatchkey - 1;
echo "剩余数量：".$re."<br/>";
echo "用户列表：<pre class="brush:php;toolbar:false">";
print_r($watchkeylist);
}else{
echo "手气不好，再抢购！";exit;
}
}else{
// $redis->hSet("watchkeylist","user_".mt_rand(1,99999),"12");
// $watchkeylist = $redis->hGetAll("watchkeylist");
echo "fail！<br/>";
echo ".no result<br/>";
echo "用户列表：<pre class="brush:php;toolbar:false">";
// var_dump($watchkeylist);
}*/
$rob_total = 100; //抢购数量
if($mywatchkey<=$rob_total){
$redis->watch("mywatchkey");
$redis->multi(); //在当前连接上启动一个新的事务。
//插入抢购数据
$redis->set("mywatchkey",$mywatchkey+1);
$rob_result = $redis->exec();
if($rob_result){
$redis->hSet("watchkeylist","user_".mt_rand(1, 9999),$mywatchkey);
$mywatchlist = $redis->hGetAll("watchkeylist");
echo "抢购成功！<br/>";
echo "剩余数量：".($rob_total-$mywatchkey-1)."<br/>";
echo "用户列表：<pre class="brush:php;toolbar:false">";
var_dump($mywatchlist);
}else{
$redis->hSet("watchkeylist","user_".mt_rand(1, 9999),'meiqiangdao');
echo "手气不好，再抢购！";exit;
}
}
?>Copier après la connexion
PHP résout le problème du big data des sites Web, du trafic important et de la concurrence élevée
La première chose dont je veux parler est la base de données. Tout d'abord, elle doit avoir une bonne structure. Essayez de ne pas utiliser * dans les requêtes. Évitez les sous-requêtes corrélées. Ajoutez des index pour les requêtes fréquentes et utilisez le tri pour remplacer les non-requêtes. accès séquentiel. Si les conditions le permettent, généralement MySQL Le serveur est mieux installé sur le système d'exploitation Linux. Concernant Apache et Nginx, il est recommandé d'utiliser nginx dans des situations de forte concurrence. Ginx est un bon substitut au serveur Apache. nginx consomme moins de mémoire. Le test officiel peut prendre en charge 50 000 connexions simultanées, et dans l'environnement de production réel, le nombre de connexions simultanées peut atteindre 20 000 à 30 000. Fermez autant que possible les modules inutiles dans PHP et utilisez Memcached est un système de mise en cache d'objets de mémoire distribuée haute performance qui transfère directement les données de la mémoire sans utiliser de base de données. Cela améliore considérablement la vitesse d'iiS ou d'Apache permettant d'optimiser la compression GZIP. site Web et compressez le contenu du site Web pour économiser considérablement le trafic du site Web. Deuxièmement, les hotlinking externes sont interdits. Le hotlink d'images ou de fichiers provenant de sites Web externes entraîne souvent beaucoup de pression de charge, donc le hotlink externe d'images ou de fichiers vers les siens
devrait être strictement limité. Heureusement, actuellement, vous pouvez simplement vous y référer. Pour contrôler les hotlinks, Apache lui-même
peut désactiver les hotlinks via la configuration. IIS dispose également de certains ISAPI tiers qui peuvent réaliser la même fonction.
Bien sûr, la falsification de références peut également être effectuée via du code pour réaliser un hotlinking, mais actuellement, peu de personnes falsifient délibérément des références vers un hotlink
Vous pouvez l'ignorer ou utiliser des moyens non techniques pour le résoudre, tels que. comme sur les photos. Ajoutez un filigrane.
Troisièmement, contrôlez le téléchargement de fichiers volumineux.
Le téléchargement de fichiers volumineux nécessitera beaucoup de trafic, et pour les disques durs non SCSI, le téléchargement d'un grand nombre de fichiers consommera du
CPU, réduisant ainsi la réactivité du site Web. Par conséquent, essayez de ne pas proposer de téléchargements de fichiers volumineux dépassant 2 Mo. Si
est requis, il est recommandé de placer les fichiers volumineux sur un autre serveur.
Quatrièmement, utilisez différents hôtes pour détourner le trafic principal.
Placez les fichiers sur différents hôtes et fournissez différentes images à télécharger aux utilisateurs. Par exemple, si vous estimez que les fichiers RSS consomment
beaucoup de trafic, utilisez des services tels que FeedBurner ou FeedSky pour placer la sortie RSS sur d'autres hôtes. être concentré sur l'hôte de FeedBurner et RSS ne sera pas disponible et occupera trop de ressources
Cinquièmement, utilisez différents hôtes pour détourner le trafic principal
Placez les fichiers sur différents hôtes et fournissez différentes images à télécharger aux utilisateurs. . Par exemple, si vous estimez que les fichiers RSS consomment beaucoup de trafic, utilisez des services tels que FeedBurner ou FeedSky pour placer la sortie RSS sur d'autres hôtes. De cette manière, la majeure partie de la pression du trafic liée à l'accès des autres personnes sera concentrée sur. L'hébergeur de FeedBurner et RSS n'occuperont pas trop de ressources.
Sixièmement, utilisez un logiciel d'analyse et de statistiques du trafic.
L'installation d'un logiciel d'analyse et de statistiques du trafic sur le site Web peut savoir instantanément où une grande partie du trafic est consommée et quelles pages doivent être optimisées. Par conséquent, une analyse statistique précise est nécessaire pour résoudre le problème de trafic. Par exemple : Google Analytics.
Contraintes pour une simultanéité élevée et une charge élevée : matériel, déploiement, système d'exploitation, serveur Web, PHP, MySQL, tests
Déploiement : séparation des serveurs, cluster de bases de données et hachage des tables de bibliothèque, mise en miroir, charge équilibrage
Classification d'équilibrage de charge : 1), round robin DNS 2) Équilibrage de charge du serveur proxy 3) Équilibrage de charge de la passerelle de traduction d'adresses 4) Équilibrage de charge NAT 5) Équilibrage de charge du proxy inverse 6) Équilibrage de charge hybride
Plan de déploiement 1 :
Champ d'application : sites Web et systèmes d'application avec un contenu statique comme corps principal ; sites Web et systèmes d'application avec des exigences élevées en matière de sécurité du système.
Serveur principal : le serveur principal
supporte la principale pression d'exécution du programme et gère les requêtes dynamiques dans le site Web ou le système d'application
pousse les pages statiques vers plusieurs serveurs de publication ;
Poussez le fichier joint vers le serveur de fichiers ;
Pour les sites Web ayant des exigences de sécurité élevées et principalement statiques, le serveur peut être placé sur le réseau interne pour bloquer l'accès depuis le réseau externe.
Serveur DB : Le serveur de base de données
supporte la pression de lecture et d'écriture de la base de données
n'échange que le volume de données avec le serveur principal et bloque l'accès au réseau externe ;
Serveur de fichiers/vidéo : le serveur de fichiers/vidéo
transporte des flux de données qui occupent de grandes ressources système et des ressources de bande passante dans le système
sert de stockage, de lecture et d'écriture ; grand entrepôt de pièces jointes ;
En tant que serveur vidéo, il disposera de capacités de traitement vidéo automatique.
Groupe de serveurs de publication :
est uniquement responsable de la publication des pages statiques et transporte la grande majorité des requêtes Web ;
effectue le déploiement d'équilibrage de charge via Nginx.
Plan de déploiement 2 :
Champ d'application : sites Web ou systèmes d'application avec un contenu interactif dynamique comme corps principal ; sites Web ou systèmes d'application avec une forte pression de charge et un budget suffisant
Groupe de serveurs Web :
Les services Web n'ont pas de relation maître-esclave et sont des conceptions redondantes parallèles
L'équilibrage de charge est obtenu via un équipement d'équilibrage de charge frontal ou un proxy inverse Nginx ;
La division des serveurs de fichiers dédiés/serveurs vidéo sépare efficacement les bus légers/lourds ;
Chaque serveur Web peut se connecter à toutes les bases de données via DEC et le diviser en maître et esclave en même temps.
Groupe de serveurs de base de données :
Supporte une pression de lecture et d'écriture de base de données relativement équilibrée
Réalise la synchronisation des données de plusieurs bases de données grâce au mappage des fichiers physiques de la base de données ;
Disque/matrice de disques partagés
Utilisé pour la lecture et l'écriture unifiées de fichiers physiques de données
Utilisé pour l'entrepôt de stockage de pièces jointes volumineuses
Assurer l'efficacité des E/S et des données de l'ensemble du système grâce à l'équilibre et à la redondance de ses propres disques physiques Sécurité ;
Caractéristiques de la solution :
Répartition raisonnable de la pression Web grâce à l'équilibrage de charge frontal
Répartition raisonnable des flux de données légers et lourds à travers le séparation des serveurs de fichiers/vidéo et des serveurs Web classiques ;
Répartir raisonnablement la pression des E/S de la base de données à travers les groupes de serveurs de base de données ;
Chaque serveur Web ne se connecte généralement qu'à un seul serveur de base de données et peut automatiquement basculer dans un temps très court grâce à la détection des battements de cœur de DEC vers les serveurs de bases de données redondants ;
L'introduction de baies de disques améliore non seulement considérablement l'efficacité des E/S du système, mais améliore également considérablement la sécurité des données.
Serveur Web :
Une grande partie de l'utilisation des ressources du serveur Web provient du traitement des requêtes Web. Dans des circonstances normales, c'est la pression générée par Apache dans le cas d'une concurrence élevée. connexions, Nginx est Apache Une bonne alternative aux serveurs. Nginx (« moteur x ») est un serveur HTTP et proxy inverse hautes performances écrit en Russie. En Chine, de nombreux sites Web et chaînes tels que Sina, Sohu Pass, NetEase News, NetEase Blog, Kingsoft Xiaoyao.com, Kingsoft iPowerWord, Xiaonei.com, YUPOO Photo Album, Douban, Xunlei Kankan, etc. utilisent des serveurs Nginx.
Avantages de Nginx :
Connexions simultanées élevées : le test officiel peut prendre en charge 50 000 connexions simultanées, et dans l'environnement de production réel, le nombre de connexions simultanées atteint 20 000 à 30 000.
Faible consommation mémoire : sous 30 000 connexions simultanées, les 10 processus Nginx démarrés ne consomment que 150M de mémoire (15M*10=150M).
Fonction de vérification de l'état intégrée : si un serveur Web dans le backend de Nginx Proxy tombe en panne, l'accès frontal ne sera pas affecté.
Stratégie : par rapport à l'ancien Apache, nous choisissons Lighttpd et Nginx, des serveurs Web avec une utilisation des ressources réduite et une capacité de charge plus élevée.
Mysql :
MySQL lui-même a une forte capacité de chargement. L'optimisation de MySQL est une tâche très compliquée, car elle nécessite en fin de compte une bonne compréhension de l'optimisation du système. Tout le monde sait que le travail sur les bases de données implique un grand nombre de requêtes, de lectures et d'écritures à court terme. En plus des techniques de développement de logiciels telles que l'indexation et l'amélioration de l'efficacité des requêtes auxquelles il faut prêter attention lors du développement du programme, le principal impact sur l'efficacité d'exécution de MySQL. du point de vue des installations matérielles, cela vient de la recherche sur le disque, des niveaux d'E/S du disque, des cycles du processeur et de la bande passante mémoire.
Effectuer l'optimisation MySQL en fonction des conditions matérielles et logicielles sur le serveur. Le cœur de l’optimisation MySQL réside dans l’allocation des ressources système, ce qui ne signifie pas allouer plus de ressources à MySQL sans limite. Dans le fichier de configuration MySQL, nous introduisons certains des paramètres les plus remarquables :
Modifier la longueur du tampon d'index (key_buffer)
Modifier la longueur de la table (read_buffer_size)
Paramètres ouverts Le nombre maximum de tables (table_cache)
Définir une limite de temps (long_query_time) pour les requêtes longues et lentes
Si les conditions le permettent, il est généralement préférable d'installer le serveur MySQL dans le système d'exploitation Linux, et non installé dans FreeBSD.
Stratégie : l'optimisation de MySQL nécessite la formulation de différents plans d'optimisation basés sur les caractéristiques de lecture et d'écriture de la base de données du système d'entreprise et la configuration matérielle du serveur, et la structure maître-esclave de MySQL peut être déployée selon les besoins.
PHP :
1. Chargez le moins de modules possible
2 Si c'est sous la plateforme Windows, essayez d'utiliser IIS ou Nginx au lieu de ce que nous avons habituellement. utiliser Apache ;
3. Accélérateur d'installation (les deux améliorent la vitesse d'exécution du code PHP en mettant en cache les résultats précompilés du code PHP et les résultats de la base de données)
eAccelerator, eAccelerator est un accélérateur PHP gratuit et open source, optimisé et dynamique. la mise en cache du contenu améliore les performances de mise en cache des scripts PHP, éliminant presque complètement la surcharge du serveur liée aux scripts PHP à l'état compilé.
Apc : Alternative PHP Cache (APC) est un cache de code optimisé gratuit et public pour PHP. Il est utilisé pour fournir un cadre gratuit, ouvert et robuste pour la mise en cache et l'optimisation du code intermédiaire PHP.
memcache : memcache est un système de mise en cache d'objets à mémoire distribuée hautes performances développé par Danga Interactive, qui est utilisé pour réduire la charge de la base de données et améliorer la vitesse d'accès dans les applications dynamiques. Le mécanisme principal consiste à maintenir une énorme table de hachage unifiée dans la mémoire. Memcache peut être utilisé pour stocker des données dans différents formats, notamment des images, des vidéos, des fichiers et des résultats de recherche dans des bases de données, etc.
Xcache : développé par des chinois. people Cache,
Stratégie : Installer l'accélérateur pour PHP.
Serveur proxy (serveur de cache) :
Squid Cache (appelé Squid) est un logiciel gratuit populaire (GNU General Public License) serveur proxy et serveur de mise en cache Web. Squid a un large éventail d'utilisations, allant de la fonction de serveur de cache frontal pour les serveurs Web afin d'augmenter la vitesse des serveurs Web en mettant en cache les requêtes pertinentes, à la mise en cache du World Wide Web, du système de noms de domaine et d'autres recherches Web pour un groupe. de personnes pour partager les ressources du réseau, pour aider le réseau en filtrant la sécurité, vers le réseau local via un réseau proxy. Squid est principalement conçu pour fonctionner sur des systèmes de type Unix.
Stratégie : l'installation du serveur proxy inverse Squid peut considérablement améliorer l'efficacité du serveur.
Tests de stress : les tests de stress sont un comportement d'assurance qualité de base qui fait partie de tout effort important de test de logiciels. L'idée de base des tests de stress est simple : au lieu d'exécuter des tests manuels ou automatisés dans des conditions normales, vous exécutez des tests dans des conditions où le nombre d'ordinateurs est petit ou les ressources système sont rares. Les ressources qui sont généralement testées sous contrainte incluent la mémoire interne, la disponibilité du processeur, l'espace disque et la bande passante réseau. La concurrence est généralement utilisée pour les tests de résistance.
Outils de tests de stress : webbench, ApacheBench, etc.
Tests de vulnérabilité : les vulnérabilités de notre système incluent principalement : les vulnérabilités d'injection SQL, les attaques de scripts intersites XSS, etc. La sécurité comprend également les logiciels système, tels que les vulnérabilités du système d'exploitation, les vulnérabilités de MySQL, Apache, etc., qui peuvent généralement être résolues par des mises à niveau.
Outil de test de vulnérabilité : Acunetix Web Vulnerability Scanner
Aucun contenu associé trouvé.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
