你們部署伺服器是幾臺，併發量是多大；怎麼進行模擬搶購的同一時間請求量是多少；怎麼防止帶刷（黃牛）如果說部署兩臺伺服器 不同的程序 怎麼實現樂觀鎖？
阿新 • • 發佈：2018-11-20
Django專案用到5臺伺服器。部署在2臺上面，因為使用者量比較少。
模擬搶購主要解決2個問題：
1.高併發對資料庫產生的壓力
2.競爭狀態下如何解決庫存的正確減少（"超賣"問題）
對於第一個問題可以使用redis解決，避免對資料庫的直接操作較少資料防護的查詢壓力。
對於“超賣”專案中使用的是“樂觀鎖”解決的。
防止黃牛代刷是個開放題目，下面提供幾種思路：
-
對於一個賬號，一次發起多個請求。
在程式入口處，一個賬號只允許接受1個請求，其他請求過濾。實現方案，可以通過Redis這種記憶體快取服務，寫入一個標誌位（只允許1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則可以繼續參加。 -
對於賬號一次傳送多個請求
可以檢測機器的ip傳送請求的頻率，假如某個固定ip的頻率特別高，就彈出驗證碼來減少請求的頻率。
樂觀鎖的實現原理：
每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料。
實現方式：可以在資料表中新增一個冗餘欄位，比如時間戳，在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本衝突 。
訂單待支付時資料庫中資料減少不？
在建立訂單時資料庫中的商品資料已經減少，在訂單未支付時資料庫中的商品資料是沒變化，只是把此訂單中商品的資訊展示而已
