Home>Article>Backend Development> How to solve high concurrency problems with PHP? (Source code attached)
The previous article introduced you to "Let us learn more about the if statement of PHP process control statement! ! ! (Source code attached)》, this article continues to introduce PHP to solve high concurrency problems
Video course recommendation →:"Concurrency Solution for Tens of Millions of Data (Theoretical and Practical)"
For example, at a highway intersection, 5 cars come in 1 second, and 5 cars pass by every second, at the highway intersection It works fine. Suddenly, only 4 cars can pass through this intersection in one second, and the traffic flow is still the same. As a result, there will definitely be a traffic jam. (The feeling of 5 lanes suddenly turning into 4 lanes)
Similarly, in a certain second, 20*500 available connection processes are working at full capacity, but there are still 10,000 new requests. , there is no connection process available, and it is expected that the system will fall into an abnormal state.
In fact, in normal non-high-concurrency business scenarios, similar situations occur. There is a problem with a certain business request interface, and the response time is extremely slow. The entire Web request The response time is very long, gradually filling up the number of available connections on the web server, and no connection process is available for other normal business requests.
The more frightening problem is that it is the behavioral characteristics of users. The more unavailable the system is, the more frequent users click. The vicious cycle eventually leads to an "avalanche" (one of the web machines hangs up, causing the traffic to be dispersed to On other machines that are working normally, the normal machines will also hang, and then a vicious circle will occur), bringing down the entire Web system.
Restart and overload protection
If an "avalanche" occurs in the system, restarting the service rashly will not solve the problem. The most common phenomenon is that after starting up, it hangs up immediately. At this time, it is best to deny traffic at the ingress layer and then restart. If services like redis/memcache are also down, you need to pay attention to "warming up" when restarting, and it may take a long time.
In flash sale and rush sale scenarios, the traffic is often beyond our system’s preparation and imagination. At this time, overload protection is necessary. Denying requests is also a protective measure if a full system load condition is detected. Setting up filtering on the front-end is the simplest way, but this approach is a behavior that is "criticized" by users. It is more appropriate to set overload protection at the CGI entry layer to quickly return direct requests from customers
Data security under high concurrency
We know that in many When threads write to the same file, there will be a "thread safety" problem (multiple threads run the same piece of code at the same time, if the result of each run is the same as that of a single-thread run, and the result is the same as expected, it is a thread safe). If it is a MySQL database, you can use its own lock mechanism to solve the problem. However, in large-scale concurrency scenarios, MySQL is not recommended. There is another problem in flash sale and rush sale scenarios, which is "over-delivery". If this aspect is not controlled carefully, excessive delivery will occur. We have also heard that some e-commerce companies conduct rush buying activities. After the buyer successfully purchases the product, the merchant does not recognize the order as valid and refuses to deliver the goods. The problem here may not necessarily be that the merchant is treacherous, but that it is caused by the risk of over-issuance at the technical level of the system.
Assume that in a certain rush-buying scenario, we only have 100 products in total, and at the last moment, we have already consumed them 99 items, only the last one left. At this time, the system sent multiple concurrent requests. The product balances read by these requests were all 99, and then they all passed this balance judgment, which eventually led to over-issuance. (Same as the scene mentioned earlier in the article)
In the picture above, it resulted in concurrent user B also "successfully buying", allowing one more person to obtain the product. This scenario is very easy to occur in high concurrency situations.
Optimization plan 1: Set the inventory field number field to unsigned. When the inventory is 0, because the field cannot be a negative number, false will be returned
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); } ?>
There are many ideas to solve thread safety, and we can start the discussion from the direction of "pessimistic lock".
Pessimistic lock, that is, when modifying data, the lock state is adopted to exclude modifications from external requests. When encountering a locked state, you must wait.
虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。
优化方案2：使用MySQL的事务，锁住操作的行
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：使用非阻塞的文件排他锁
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); ?>
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
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 "抢购成功！
"; $re = $mywatchkey - 1; echo "剩余数量：".$re."
"; echo "用户列表："; print_r($watchkeylist); }else{ echo "手气不好，再抢购！";exit; } }else{ // $redis->hSet("watchkeylist","user_".mt_rand(1,99999),"12"); // $watchkeylist = $redis->hGetAll("watchkeylist"); echo "fail！
"; echo ".no result
"; echo "用户列表："; // 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 "抢购成功！
"; echo "剩余数量：".($rob_total-$mywatchkey-1)."
"; echo "用户列表："; var_dump($mywatchlist); }else{ $redis->hSet("watchkeylist","user_".mt_rand(1, 9999),'meiqiangdao'); echo "手气不好，再抢购！";exit; } } ?>
推荐学习：《PHP视频教程》
The above is the detailed content of How to solve high concurrency problems with PHP? (Source code attached). For more information, please follow other related articles on the PHP Chinese website!