우리가 일반적으로 웹 시스템의 처리 속도를 측정하는 지표는 QPS(Query Per Second, 초당 처리되는 요청 수)입니다. 이 지표는 초당 수만 건의 높은 동시성 시나리오를 해결하는 데 매우 중요합니다. . 예를 들어 비즈니스 요청을 처리하는 평균 응답 시간이 100ms라고 가정합니다. 동시에 시스템에 Apache 웹 서버가 20개 있고 MaxClients가 500(Apache 연결 최대 수를 나타냄)으로 구성되어 있다고 가정합니다.
그러면 우리 웹 시스템의 이론적 최고 QPS는 (이상적인 계산 방법):
20*500/0.1 = 100000(100,000 QPS)
어? 우리 시스템은 1초에 100,000건의 요청을 처리할 수 있는 매우 강력한 것 같습니다. 5w/s의 플래시 세일은 "종이 호랑이"인 것 같습니다. 물론 실제 상황은 그다지 이상적이지 않습니다. 실제 높은 동시성 시나리오에서는 컴퓨터의 부하가 높으며 이때 평균 응답 시간이 크게 늘어납니다.
웹 서버의 경우 Apache가 더 많은 연결 프로세스를 열수록 CPU가 처리해야 하는 컨텍스트 전환이 많아지며, 이는 CPU 소비를 증가시키고 평균 응답 시간의 증가로 직결됩니다. 따라서 위에서 언급한 MaxClient 수는 CPU, 메모리 등 하드웨어 요소를 고려하여 고려해야 합니다. Apache 자체 abench를 통해 테스트하고 적합한 값을 얻을 수 있습니다. 그런 다음 메모리 작업 수준에서 스토리지로 Redis를 선택합니다. 동시성이 높은 상태에서는 스토리지 응답 시간이 중요합니다. 네트워크 대역폭도 한 요인이지만 이러한 요청 패킷은 일반적으로 상대적으로 작으며 요청에 병목 현상이 발생하는 경우가 거의 없습니다. 로드 밸런싱으로 인해 시스템 병목 현상이 발생하는 경우는 거의 없으므로 여기서는 이에 대해 논의하지 않습니다.
그러면 문제는 우리 시스템이 5w/s의 높은 동시성 상태에서 평균 응답 시간이 100ms에서 250ms로 변경된다고 가정할 때입니다(실제 상황은 그 이상).
20 *500/0.25 = 40000(40,000QPS)
따라서 우리 시스템에는 초당 50,000개의 요청에 대해 40,000QPS가 남게 되며 10,000의 차이가 있습니다.
예를 들어 고속도로 교차로에서는 1초에 5대의 차량이 오고 5대의 차량이 지나가며 고속도로 교차로는 정상적으로 작동합니다. 갑자기 이 교차로는 1초에 4대의 차량만 지나갈 수 있고, 교통량은 여전히 그대로이므로 교통 정체가 불가피할 것입니다. (5레인이 갑자기 4레인으로 변한 느낌)
마찬가지로 어느 순간 20*500개의 연결 프로세스가 풀가동을 하고 있는데 여전히 10,000개의 신규 요청이 있어 연결이 되지 않습니다. 프로세스를 사용할 수 없으며 시스템이 비정상적인 상태에 빠질 것으로 예상됩니다.
실제로 동시성이 높지 않은 일반적인 비즈니스 시나리오에서는 특정 비즈니스 요청 인터페이스에 문제가 있으며 응답 시간이 매우 느립니다. . 전체 웹 요청 응답 시간이 매우 길어서 웹 서버에서 사용 가능한 연결 수가 점차 채워지고 다른 일반적인 비즈니스 요청에는 연결 프로세스를 사용할 수 없습니다.
더 무서운 문제는 사용자의 행동 특성입니다. 시스템을 사용할 수 없을수록 사용자가 클릭하는 빈도가 높아집니다. 이러한 악순환은 결국 "눈사태"로 이어집니다. 정상적으로 작동하는 다른 머신에서는 정상적인 머신도 정지되고, 이로 인해 웹 시스템 전체가 다운되는 악순환이 발생하게 됩니다.
3. 재시작 및 과부하 보호
시스템에 "눈사태"가 발생한 경우 성급하게 서비스를 다시 시작해도 문제가 해결되지 않습니다. 가장 흔한 현상은 시동을 걸자마자 바로 끊기는 현상입니다. 이때는 수신 계층에서 트래픽을 거부한 후 다시 시작하는 것이 가장 좋습니다. redis/memcache 등의 서비스도 다운된 경우, 재시작 시 '워밍업'에 주의해야 하며, 시간이 오래 걸릴 수 있습니다.
플래시 세일 및 긴급 세일 시나리오에서는 트래픽이 시스템의 준비와 상상을 넘어서는 경우가 많습니다. 이때 과부하 보호가 필요합니다. 전체 시스템 로드 조건이 감지된 경우 요청을 거부하는 것도 보호 조치입니다. 프런트 엔드에서 필터링을 설정하는 것이 가장 간단한 방법이지만 이 접근 방식은 사용자로부터 "비난"을 받는 동작입니다. 더 적절한 것은 CGI 항목 계층에서 과부하 보호를 설정하여 고객의 직접 요청을 신속하게 반환하는 것입니다.
높은 동시성에서 데이터 보안
여러 스레드가 동일한 파일에 쓸 때( 여러 스레드가 동일한 코드 조각을 동시에 실행합니다. 각 실행의 결과가 단일 스레드 실행의 결과와 동일하고 결과도 스레드로부터 안전합니다. MySQL 데이터베이스인 경우 자체 잠금 메커니즘을 사용하여 문제를 해결할 수 있습니다. 그러나 대규모 동시성 시나리오에서는 MySQL이 권장되지 않습니다. 플래시세일과 급세일 시나리오에는 또 다른 문제가 있는데, 바로 '과잉 전송'입니다. 이 부분을 주의 깊게 제어하지 않으면 과도한 전송이 발생하게 됩니다. 또한 일부 전자상거래 회사에서는 구매자가 상품을 성공적으로 구매한 후에도 판매자가 주문이 유효한 것으로 인식하지 못하고 상품 배송을 거부하는 경우가 많다고 들었습니다. 여기서 문제는 반드시 가맹점이 배신적이라는 것이 아니라, 시스템의 기술적 수준에서 과잉 발행의 위험이 있기 때문에 발생한다는 점일 수 있습니다.
1. 초과배송 사유
특정 긴급 세일 시나리오에서 총 100개의 제품만 있다고 가정해 보겠습니다. 마지막 순간에 99개의 제품을 소비했고 마지막 제품만 남았습니다. 이때 시스템은 여러 개의 동시 요청을 보냈고, 이러한 요청으로 읽은 상품 잔액은 모두 99개였으며 모두 이 잔액 판단을 통과하여 결국 초과 발행으로 이어졌습니다. (앞서 기사에서 언급한 장면과 동일)
위 사진에서 동시유저 B님도 '구매에 성공'하여 한 분이 더 상품을 획득하실 수 있게 되었습니다. 이 시나리오는 동시성이 높은 상황에서 발생하기가 매우 쉽습니다.
최적화 계획 1: 인벤토리 필드 번호 필드를 unsigned로 설정합니다. 인벤토리가 0이면 필드가 음수일 수 없으므로 false가 반환됩니다
<?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);
}
?>로그인 후 복사
2.
스레드 안전성을 해결하기 위한 많은 아이디어가 있는데, "비관적 잠금" 방향에서 논의를 시작할 수 있습니다.
비관적 잠금, 즉 데이터 수정 시 잠금 상태를 채택하여 외부 요청에서 수정 사항을 제외합니다. 잠긴 상태가 발생하면 기다려야 합니다.
위의 솔루션으로 스레드 안전성 문제가 해결되었지만 우리의 시나리오는 "높은 동시성"이라는 점을 잊지 마세요. 즉, 그러한 수정 요청이 많이 있을 것이며 각 요청은 "잠금"을 기다려야 합니다. 일부 스레드는 이 "잠금"을 잡을 기회가 전혀 없을 수 있으며 그러한 요청은 거기에서 종료됩니다. 동시에 이러한 요청이 많아지면 시스템의 평균 응답 시간이 즉시 증가하게 되며 결과적으로 사용 가능한 연결 수가 소진되고 시스템이 예외에 빠지게 됩니다.
최적화 계획 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");
}
?>로그인 후 복사
3.FIFO 대기열 아이디어
그렇다면 위의 시나리오를 약간 수정해 보겠습니다. 요청을 대기열에 넣고 FIFO(First In First Out, First In First Out)를 사용하면 일부 요청이 잠금을 획득하지 못하게 됩니다. 이렇게 보니 멀티스레딩을 강제로 싱글스레딩으로 바꾸는 듯한 느낌이 드시나요?
이제 잠금 문제가 해결되었으며 모든 요청은 "선입 선출" 대기열에서 처리됩니다. 그러면 새로운 문제가 발생합니다. 동시성이 높은 시나리오에서는 요청이 많기 때문에 큐 메모리가 순간적으로 "폭발"될 수 있으며 시스템이 다시 비정상적인 상태에 빠지게 됩니다. 또는 대규모 메모리 대기열을 설계하는 것도 해결책입니다. 그러나 시스템이 대기열에 있는 요청을 처리하는 속도는 대기열로 유입되는 미친 개수와 비교할 수 없습니다. 즉, 대기열에 있는 요청 수가 점점 더 많이 누적되고 결국 웹 시스템의 평균 응답 시간은 여전히 크게 떨어지며 시스템은 여전히 예외 상태에 빠지게 됩니다.
4. 파일 잠금 아이디어
일일 IP가 높지 않거나 동시성 수가 그리 많지 않은 애플리케이션의 경우 일반적으로 고려할 필요가 없습니다! 일반적인 파일 조작 방법에는 전혀 문제가 없습니다. 하지만 동시성이 높으면 파일을 읽고 쓸 때 다음 파일에 대해 여러 프로세스가 작동할 가능성이 높습니다. 이때 파일에 대한 액세스를 독점하지 않으면 데이터 손실이 발생하기 쉽습니다
최적화 계획 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);
?>로그인 후 복사
5. 낙관적 잠금 아이디어
이번에는 "낙관적 잠금"에 대한 아이디어를 논의할 수 있습니다. 낙관적 잠금은 "비관적 잠금"에 비해 더 완화된 잠금 메커니즘을 채택하며 대부분 버전 업데이트를 사용합니다. 구현에서는 이 데이터에 대한 모든 요청을 수정할 수 있지만 데이터의 버전 번호를 얻을 수 있습니다. 버전 번호가 일치하는 요청만 성공적으로 업데이트할 수 있으며 다른 요청은 실패로 반환됩니다. 이 경우 큐 문제를 고려할 필요는 없지만 CPU의 계산 오버헤드가 증가합니다. 그러나 전반적으로 이것이 더 나은 솔루션입니다.
Redis의 watch와 같이 "낙관적 잠금" 기능을 지원하는 소프트웨어와 서비스가 많이 있습니다. 이 구현을 통해 우리는 데이터 보안을 보장합니다.
최적화 솔루션 5: 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;
}
}
?>로그인 후 복사
위 내용은 높은 동시성에서 플래시 세일 아이디어 및 데이터 보안 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
