對於重複提交，想到的最簡單的方案就是該方法保證冪等性，所謂冪等性就是f(f(x))=f(x)多次運算結果都是一致的。比如對於innodb儲存引擎，rr級別以上的select查詢就天然具有冪等性。
首先重複提交的原因有許多，比如惡意的重複提交，網路重發，分布式rpc的try重發，nginx重發等情況等等。
下面給乙個網路重發的案例。
其中，businesskey為自定義的業務key，用於表示這些key的組合在expires是操作應該是唯一的
action: 表示失敗後的邏輯處理
expires:鎖定的時間
timeout：業務不允許的重複執行最大值timeout
分布式鎖的實現需要注意以下問題：
確保只能釋放自己的鎖，確保鎖可重入性
避免鎖超時當前執行緒掛掉，其他執行緒獲取不到鎖的場景
原子性：當通過setnx設定鎖時，最好設定鎖自動過期時間以預防死鎖存在的隱患；確保加鎖與釋放鎖的原子性：redis支援lua指令碼並保證其原子性
redis節點故障後，主備切換的資料一致性：由於主從同步具有延遲性，在主節點故障後可能導致同一資源的鎖被多個客戶端持有。解決思路參考redlock的分布式一致性演算法。當然這要消耗一定的時間來保證鎖的正確獲取。
時鐘漂移問題：由於鎖的過期時間依賴於伺服器時間，而伺服器時間可能發生跳躍，所以會存在多個客戶端同時獲取到鎖的情況發生——這個問題在實際中我暫時沒有考慮，目前redlock也並沒有完全解決該問題。
當然，如果業務中的資料庫中已經定義了唯一索引，就沒有必要再去引用註解redislock。
重複提交解決方案
struts 的token 機制能夠很好的解決表單重複提交的問題，基本原理是 伺服器端在處理到達的請求之前，會將請求中包含的令牌值與儲存在當前使用者會話中的令牌值進行比較，看是否匹配。在處理完該請求後，且在答 送給客戶端之前，將會產生乙個新的令牌，該令牌除傳給客戶端以外，也會將使用者會話中儲存的舊的...
重複提交的解決方案
解決方案 js判斷 token驗證 想法一 應將按鈕隱藏或變灰，使其不可重複點選。var flog true function onsubmit success function data 想法二 設定引數，前後臺約定好特殊值，然後只有等於特殊值的時候，該資料才是有效的。var flog true ...
重複提交兩種解決方案
時序圖 新增流程圖 code生成規則 sessionid uuid，防止csrf攻擊 code校驗規則 判斷code相等後，從session中移除code的操作，會放在同步 塊中執行。如果所有請求用同乙個鎖物件，會有一定的效能消耗，為了降低同步鎖引起的效能消耗，根據不同的sessionid建立不同的...