1樓：
樓主我也碰到這個問題，就是使用者可能通過複製鏈結出來，直接放在瀏覽器上面按F5快速重新整理請求，有多條請求到伺服器，結果相當於多次執行了插入資料庫；通過檔案鎖什麼的都無效，因為同時請求到的時候，鎖可能都沒加好！
2樓：
這個實際上是併發問題，只針對的是同乙個使用者併發，而不是訪問太大而造成的高併發。
簡單地說，假設你有乙個發貨介面：http://
這個介面發貨介面再發貨前，需要驗證使用者是否合法。假設我現在有自己的使用者名稱和密碼，那麼寫乙個指令碼是可以模擬登入的。就在這個時候我可以獲得驗證後的token。
Anyway，這裡無論是什麼token我都可以獲得，為什麼？因為這是我自己的帳號，我知道密碼呀！
這個時候如果我們有這麼乙個邏輯：去判斷使用者是否獲獎，如果沒有，那麼我們就發貨。
如果你的後端直接去select判斷，如果有就不發貨，die掉程式；如果沒有，那麼就發貨，insert資料。
這樣子做是很不穩妥的，特別是對於這種發貨或者鑑權的介面。一定不要這麼幹。我們只需要通過一些壓力測試，例如ab。
將所有的引數，無論post或者get，還是cookie以及你登入後的token引數一起發給http://
介面。隨意併發50個，請求1000個，此時一定會寫入多個資料！（前提記錄沒有唯一約束）
解決方法：
1、根據業務，加唯一約束。例如訂單表，你可以對流水號或者訂單號增加unique。
2、根據業務，如果不能加唯一約束，通過加鎖實現。例如mysql的get_lock和release_lock可以去顯示。當然自己建立乙個鎖表也是可以的，將整個請求鎖住。
3、如果mysql效能不好，就使用一些快取系統去實現，例如redis或者Memcache。
4、非同步佇列。
3樓：魚游醬
不存在正不正規， 只有合不合適....
客觀的來說, 用唯一鍵放在資料庫級別去處理, 個人感覺還不錯, 能及時給客戶端響應(註冊成功 or 失敗), 放在佇列裡面畢竟存在乙個響應延時的問題(可能量小的時候並不高), 具體還是要根據你們業務的量, or 產品設計/業務流程上的要求(即時響應 or 是否對其他相關聯的業務有影響)
mysql高併發場景下重複插入如何保證唯一性？
runhua 在MySQL的InnoDB引擎中解決這類問題至少有4種思路 加唯一索引 有兩種方案，一是新建表，而是改造表，目的都是能新增上唯一索引，由唯一索引來保證插入資料的唯一性，其中改造表方案比較優雅 鎖表 採用顯式鎖表和解鎖表的語句LOCK TABLES和UNLOCK TABLES來保證併發重...
Mysql造成死鎖的原因有哪些呢？如何避免？
在 MySQL 中，如果兩個不同的事務在執行時，互相持有了對方所需的鎖，此時由於它們都在等待某個資源，永遠不會釋放自己獲得的鎖，因此就會產生死鎖 deadlock 以下是乙個產生死鎖的示例。首先，在客戶端 A 中建立乙個表 t，它只有一行資料。然後開始乙個事務，並且通過共享查詢模式獲取該行資料上的 ...
如何避免二重敬語 ？
開個腦洞，說成 還原成 現在唯一的問題是還沒有被廣泛接受形成慣用說法。等形成後變成既定事實，這個問題就解決了。沒有熟飯，我們就把生公尺做成熟飯吧。 Revised 先說結論 語法上完全正確。無需避開，無需替代。關於 是否二重敬語 我認為 並非二重敬語。一般的二重敬語指的是尊敬語 自謙語疊加導致的過分...