秒殺程式基本思路

2022-06-06 23:30:19 字數 1704 閱讀 5675

做秒殺活動的時候,最難應付的應該是在開始秒殺的那一瞬間,如何解決成千上萬個使用者同時造成的高併發問題。只有較好地解決這些問題,才能讓你的程式 在這麼多秒殺使用者中,找到真正的秒殺得主。雖然之前做的秒殺活動最多的併發數也就在幾十個,不過,還是積累了一些經驗,在此記錄並分享出來,希望對其他開 發秒殺產品的開發者有所幫助。

一、mysql連線數

最開始,我沒有對mysql的併發連線數做調整,結果某一次秒殺使用者多的時候,就提示mysql連線數過多,拒絕連線的提示。原來,mysql預設 的併發連線數是100,這對於秒殺瞬間來說,是遠遠不夠的。可以通過在/etc/my.cnf檔案中設定max_connections引數即可。比 如:max_connections = 800。

二、php-cgi程序數

後來,在之後的某一次秒殺中,在點選開始秒殺出現驗證的時候,整個頁面需要卡上10s左右才出來,我認為是php-cgi程序處理不過來,所以將其由最開始的100提高到256,這對於記憶體足夠大的伺服器來說,能盡快響應等待的請求,讓使用者盡快地得到響應。

三、session數目

不過,第二步在後來的進一步跟蹤中,發現還並不是導致頁面變慢的主要問題——真正的罪魁禍首是session。原來的session過期時間設定的 是30天,在session表中,儲存了超過40萬條的記錄,在驗證顯示的頁面,就需要利用到session來儲存驗證碼,對乙個40萬的 session表操作,讓mysql要索表0.5s,因此頁面響應的速度急劇下降。後來通過刪除無用的session資訊,將session表記錄減低到 7000,並將session有效時間調整為7天,就將頁面的響應速度很快地降低下來了。

四、驗證

驗證用到session也增加了資料庫操作次數,因此我考慮將驗證從session剝離開來,直接利用memcached來儲存使用者的驗證 碼資訊。使用者請求的時候,分配乙個唯一的sessionkey,使用者請求驗證時,需要通過sessionkey來請求,同時,系統儲存乙個鍵值對 (sessionkey=>validcode)到memcached,這樣的話,將請求驗證碼的資料庫操作次數將為0,對於秒殺系統的響應速 度也提供了極大的方便。

五、秒殺得主的決策

最開始,我們採取了如下的秒殺得主判定策略:秒殺者檢查秒殺產品的秒殺得主是否為空,如果為空,則認定自己是秒殺得主,並將秒殺產品的秒殺得主設定為自己。(如下圖所示)

秒殺者自己判定似乎否為秒殺得主

圖一、秒殺者自己判定似乎否為秒殺得主

在內部測試期間,人數比較少,這種策略一直都沒有出問題。不過到正式上線的時候,這種策略在高併發的情形下,則變得不堪一擊:因為,在使用者a檢查自 己是否是秒殺得主的時候,已經有使用者b,設定使用者c、使用者d也在進行這項檢查,而這個時候,使用者a還沒有將自己是秒殺得主的訊息寫入秒殺產品的記錄中,所 以,使用者b、c、d都會認為自己也是秒殺得主。

我們曾經想過,將相關的資料操作用memcached快取起來,不過,其實,雖然memcached在響應速度上雖然比mysql要快,但在高併發的情況下,它也依然無能為力,依然會遭遇到同樣的問題。

後來,我們決定改變策略:使用者秒殺的時候只讓其插入秒殺記錄,並不去判斷自己是不是秒殺得主;判斷得主的事情交給裁判——定時任務完成。定時任務根據各個使用者秒殺時間的先後順序,很容易就可以知道誰是秒殺得主,並將秒殺產品的秒殺得主設定為這個使用者。(如下圖所示)

由定時程式判定誰是秒殺得主

圖二、由定時程式判定誰是秒殺得主

我想,我們在各種比賽中,都需要由裁判來主持公道,也是同樣的道理吧。

通過做好如上所述的步驟,相信您的秒殺活動一定能更加完好地執行。

python unittest基本思路

unittest是python中的單元測試框架,但也可以作為selenium自動化測試框架。基本思路主要分為以下三步 1.設計測試用例,注意點主要是要包含測試類和測試方法 class unittest class unittest.testcase 必須包含unittest模組下的testcase類...

快速排序基本思路

尊重原創,原文鏈結 今天看到大神寫的一篇快速排序的部落格,肅然起敬,覺得原來快速排序這麼簡單 下面進行簡單的試試 快速排序的基本思想是 1 先從數列中取出乙個數作為基準數 2 分割槽過程,將比這個數大的數全放到它的右邊,小於或等於它的數全放到它的左邊 3 再對左右區間重複第二步,直到各區間只有乙個數...

堆排序基本思路

前提 1 不建立新的空間,只在當前帶排序陣列arr中做處理 2 公升序,大頂堆。思路 1 首先建立大頂堆。建立大頂堆的過程 heapinsert 是自下而上不斷調整新加入元素的位置 2 交換首次建立好大頂堆的首尾元素 最大元素沉底,這也是為什麼利用大頂堆做公升序 同時用於重建大頂堆的arr尺寸減1 ...