接口冪等

? ?對于冪等的考慮，主要解決兩點前后端交互與服務間交互。這兩點有時都要考慮冪等性的實現。從前端的思路解決 的話，主要有三種：前端防重、PRG模式、Token機制。

前端防重

? ?通過前端防重保證冪等是最簡單的實現方式，前端相關屬性和JS代碼即可完成設置。可靠性并不好，有經驗的人員 可以通過工具跳過頁面仍能重復提交。主要適用于表單重復提交或按鈕重復點擊。

PRG模式

? ? PRG模式即POST-REDIRECT-GET。當用戶進行表單提交時，會重定向到另外一個提交成功頁面，而不是停留在原 先的表單頁面。這樣就避免了用戶刷新導致重復提交。同時防止了通過瀏覽器按鈕前進/后退導致表單重復提交。 是一種比較常見的前端防重策略。

token機制

??借助redis單線程和incr是原子性的特點。當第一次獲取token時，以token作為key，對其進行自增。 然后將token進行返回，當客戶端攜帶token訪問執行業務代碼時，對于判斷token是否存在不用刪除，而是對其繼 續incr。如果incr后的返回值為2。則是一個合法請求允許執行，如果是其他值，則代表是非法請求，直接返回。

? ?那如果先刪除token再執行業務呢？其實也會存在問題，假設具體業務代碼執行超時或失敗，沒有向客戶端返回 明確結果，那客戶端就很有可能會進行重試，但此時之前的token已經被刪除了，則會被認為是重復請求，不再進 行業務處理。

這種方案無需進行額外處理，一個token只能代表一次請求。一旦業務執行出現異常，則讓客戶端重新獲取令牌， 重新發起一次訪問即可。推薦使用先刪除token方案

? ?但是無論先刪token還是后刪token，都會有一個相同的問題。每次業務請求都回產生一個額外的請求去獲取 token。但是，業務失敗或超時，在生產環境下，一萬個里最多也就十個左右會失敗，那為了這十來個請求，讓其 他九千九百多個請求都產生額外請求，就有一些得不償失了。雖然redis性能好，但是這也是一種資源的浪費。

---

推薦閱讀

業務冪等性技術架構體系

記一次線上SQL死鎖事故：如何避免死鎖