Le dernier article vous a présenté "Apprenons-en plus sur l'instruction if de l'instruction de contrôle de flux PHP ! ! ! (Code source ci-joint) ", cet article continue de présenter PHP pour résoudre des problèmes de haute concurrence
Recommandation de cours vidéo → : "Solution simultanée pour des dizaines de millions de données (théorique + pratique)"
Par exemple, à une intersection d'autoroute, 5 voitures arrivent en 1 seconde, et 5 voitures passent toutes les secondes. Le carrefour 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.
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 dans de nombreux cas les threads écrivent dans le même fichier, il y aura un problème de « sécurité des threads » (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 le résultat d'une exécution avec un seul thread, et le résultat est le même que prévu, c'est un 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 la « livraison excessive ». Si cet aspect n'est pas soigneusement contrôlé, une livraison excessive 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.
Supposons que dans un scénario d'achat précipité, nous n'ayons que 100 produits au total, et au dernier moment , nous leur avons déjà consommé 99 articles, 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']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);
}
?>
虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。
优化方案2：使用MySQL的事务，锁住操作的行
<?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");
}
?>那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。
然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。
优化方案4：使用非阻塞的文件排他锁
<?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);
?> <?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);
?>这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。
有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。
优化方案5：Redis中的watch
<?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($mywatchkeywatch("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;
}
}
?>推荐学习：《PHP视频教程》
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
