【轉】記錄PHP、MySQL在高並發情境下產生的一次事故

標籤：

看了一篇網友日誌，感覺工作中值得借鑒，原文如下：

 

事故描述

在一次項目中，上線了一新功能之後，陸陸續續的有客服向我們反應，有使用者的個別道具數量高達42億，但是當時一直沒有到證據表示這是，確實存在，並且直覺告訴我們，這是不可能的，就一直沒有在意，直到後來真的發現了一個使用者確實是42億，當時我們整個公司都震驚了，如果有大量使用者是這樣的情況，公司要虧損幾十萬，我們的老大告訴我們，肯定是什麼地方資料溢出的，最後我們一幫人，瘋了似的查代碼，發現……

如果按照正常的程式邏輯走下去，代碼是完全沒問題，但是我發現了一個地方，如果在高並發的情況下，是會走出錯誤的程式邏輯的，為什麼我看到了，很簡單，我在上一家公司，因為這個問題困擾了我一個多月，真是刻骨銘心呀！不多說了，說多了都是淚呀！上代碼，重現情境（以下都是一些簡單的代碼，用來重現情境）,道具名就定義為props。

<?phpmysql_connect("localhost", "mysql_user", "mysql_password");mysql_select_db("user");$consume_props_count = 10; // 要消耗的道具數量$select = ‘SELECT `count` from `user` where `userid`=123456‘;$query = mysql_query($select);$row = mysql_fetch_assoc($query); // 對比當前道具數量if ($row[‘count‘] < $consume_props_count) {    return false;}// 扣除道具數量$update = "update `user` set `count`=`count`-{$consume_props_count}";$query = mysql_query($update);return mysql_num_rows($query);?>

 

大家可以看到，如果按照正常的扣除道具的流程來走，這個是沒有問題的，但是在高並發情境下，兩次扣道具的查詢極有可能擷取的是同一個結果，然後他們都能通過對比當前道具數量這一步邏輯，但是加入第一次的扣道具的操作把道具扣光了，或者扣的不夠第二次繼續扣了，想想會發生什麼樣的情況！

坑爹了！第二次會把道具數量扣為負數。

但是這依然不能解釋這42億的溢出那裡來的！哎，禍不單行的古語再次應驗了，我們的count欄位的資料類型是Unsigned int，坑爹的MySQL，假如欄位是Unsigned int，然後輸入了一個負數，它就會讓這個數字變為42億這個巨大的數值。

看明白了吧！這42億就是這麼來的，坑啊！

解決方案的話，可以在update的sql改成這樣

1

<?php

2	$update = "UPDATE `user` SET `count`=(CASE WHEN `count`<={$consume_props_count} THEN 0 ELSE `count`-{$consume_props_count} END) WHERE `userid`=123456"

3

?>

這樣，就不會在扣成負數了，另外以防萬一，還要將Unsigned int的欄位類型，改為int。

【轉】記錄PHP、MySQL在高並發情境下產生的一次事故