高併發下的資料安全
我們知道在多執行緒寫入同乙個檔案的時候，會存現「執行緒安全」的問題（多個執行緒同時執行同一段**，如果每次執行結果和單執行緒執行的結果是一樣的，結果和預期相同，就是執行緒安全的）。如果是mysql資料庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規模併發的場景中，是不推薦使用mysql的。秒殺和搶購的場景中，還有另外乙個問題，就是「超發」，如果在這方面控制不慎，會產生傳送過多的情況。我們也曾經聽說過，某些電商搞搶購活動，買家成功拍下後，商家卻不承認訂單有效，拒絕發貨。這裡的問題，也許並不一定是商家奸詐，而是系統技術層面存在超發風險導致的。
超發的原因
假設某個搶購場景中，我們一共只有100個商品，在最後一刻，我們已經消耗了99個商品，僅剩最後乙個。這個時候，系統發來多個併發請求，這批請求讀取到的商品餘量都是99個，然後都通過了這乙個餘量判斷，最終導致超發。（導致了併發使用者b也「搶購成功」，多讓乙個人獲得了商品。這種場景，在高併發的情況下非常容易出現。）
優化方案1：將庫存欄位number欄位設為unsigned，當庫存為0時，因為字段不能為負數，將會返回false
<?php
//優化方案1：將庫存欄位number欄位設為unsigned，當庫存為0時，因為字段不能為負數，將會返回false
include('./mysql.php');
$username = 'wang'.rand(0,1000);
//生成唯一訂單
function build_order_no()
//記錄日誌
function insertlog($event,$type=0,$username)
function insertorder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number)
//模擬下單操作
//庫存是否大於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)
$order_sn=build_order_no();
//庫存減少
$sql="update ih_store set number=number- where sku_id='$sku_id' and number>0";
$store_rs=mysqli_query($conn,$sql);
if($store_rs)else
}else
?>
悲觀鎖，也就是在修改資料的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。
雖然上述的方案的確解決了執行緒安全的問題，但是，別忘記，我們的場景是「高併發」。也就是說，會很多這樣的修改請求，每個請求都需要等待「鎖」，某些執行緒可能永遠都沒有機會搶到這個「鎖」，這種請求就會死在那裡。同時，這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連線數被耗盡，系統陷入異常。
優化方案2：使用mysql的事務，鎖住操作的行
<?php
//優化方案2：使用mysql的事務，鎖住操作的行
include('./mysql.php');
//生成唯一訂單號
function build_order_no()
//記錄日誌
function insertlog($event,$type=0)
//模擬下單操作
//庫存是否大於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) where sku_id='$sku_id'";
$store_rs=mysqli_query($conn,$sql);
if($store_rs)else
}else
?>
那好，那麼我們稍微修改一下上面的場景，我們直接將請求放入佇列中的，採用fifo（first input first output，先進先出），這樣的話，我們就不會導致某些請求永遠獲取不到鎖。看到這裡，是不是有點強行將多執行緒變成單執行緒的感覺哈。
然後，我們現在解決了鎖的問題，全部請求採用「先進先出」的佇列方式來處理。那麼新的問題來了，高併發的場景下，因為請求很多，很可能一瞬間將佇列記憶體「撐爆」，然後系統又陷入到了異常狀態。或者設計乙個極大的記憶體佇列，也是一種方案，但是，系統處理完乙個佇列內請求的速度根本無法和瘋狂湧入佇列中的數目相比。也就是說，佇列內的請求會越積累越多，最終web系統平均響應時候還是會大幅下降，系統還是陷入異常。
4. 檔案鎖的思路
對於日ip不高或者說併發數不是很大的應用，一般不用考慮這些！用一般的檔案操作方法完全沒有問題。但如果併發高，在我們對檔案進行讀寫操作時，很有可能多個程序對進一檔案進行操作，如果這時不對檔案的訪問進行相應的獨佔，就容易造成資料丟失
優化方案3：使用非阻塞的檔案排他鎖
<?php
//優化方案4：使用非阻塞的檔案排他鎖
include ('./mysql.php');
//生成唯一訂單號
function build_order_no()
//記錄日誌
function insertlog($event,$type=0)
$fp = fopen("lock.txt", "w+");
if(!flock($fp,lock_ex | lock_nb))
//下單
$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) where sku_id='$sku_id'";
$store_rs = mysqli_query($conn,$sql);
if($store_rs)else
}else
fclose($fp);
?>
這個時候，我們就可以討論一下「樂觀鎖」的思路了。樂觀鎖，是相對於「悲觀鎖」採用更為寬鬆的加鎖機制，大都是採用帶版本號（version）更新。實現就是，這個資料所有請求都有資格去修改，但會獲得乙個該資料的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗。這樣的話，我們就不需要考慮佇列的問題，不過，它會增大cpu的計算開銷。但是，綜合來說，這是乙個比較好的解決方案。
有很多軟體和服務都「樂觀鎖」功能的支援，例如redis中的watch就是其中之一。通過這個實現，我們保證了資料的安全。
優化方案4：redis中的watch
<?php
$redis = new redis();
$result = $redis->connect('127.0.0.1', 6379);
echo $mywatchkey = $redis->get("mywatchkey");
/* //插入搶購資料
if($mywatchkey>0)
else
}else*/
$rob_total = 100; //搶購數量
if($mywatchkey<=$rob_total)else
}?>
優化秒殺搶購時的超發
高併發下的資料安全 我們知道在多執行緒寫入同乙個檔案的時候，會存現 執行緒安全 的問題 多個執行緒同時執行同一段 如果每次執行結果和單執行緒執行的結果是一樣的，結果和預期相同，就是執行緒安全的 如果是mysql資料庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規模併發的場景中，是不推薦使用my...
如何解決秒殺商品時，商品超賣的情況
文章的思路主要 於 解決方案 以下方案都是基於分布式的redis快取 1.用佇列解決大併發 建立一條佇列，將每個請求加入到佇列中，然後非同步獲取佇列資料進行處理，把多執行緒的事情變成單執行緒，處理完乙個就從佇列中刪除乙個。但是會出現乙個現象，請求特別多的時候，一瞬間將redis佇列記憶體撐爆，導致系...
你的工資是老闆發的嗎？
經常聽到有人抱怨 公司給我發的工資太少了！我的付出和公司不成正比。那麼，你的工資是老闆發的嗎？從表面看來，你的工資是每個月公司財務發到你的工資卡上，是公司發給你的，但真的是這樣嗎？首先，乙個公司在發布招聘職位時，必定會有乙個對這個職位的期望薪資，就是願意花多少錢來招聘乙個符合職位要求的員工。你去應聘...