利用redis緩存解決高併發下後端重複請求措施

 最近在進行壓力測試的時候發如今高併發下，有些接口極可能由於重複請求致使對數據庫操做出來的數據不是你想要的那個樣子。好比，用戶簽到，你只想讓用戶一天簽到一次，爲了防止簽到屢次，你對於每次強求，都去查詢數據庫今天是否是已經簽到了，若是簽了，就不讓繼續簽到，若是沒簽到，插入簽到數據，更新積分數據什麼的。可是數據庫操做是有時間的，在高併發下這種方式明顯是不能限制重複請求提交的，有可能一個用戶一天簽到好幾回，只要這個提交時間在很短的範圍內就行（親測確實是這樣的）。

     因而就引出了今天要討論的問題，如何處理重複提交的問題。
    首先看看準確的出現重複請求問題的緣由（容老夫ctrl+v一段文字)：

     在業務開發中，咱們常會面對防止重複請求的問題。當服務端對於請求的響應涉及數據的修改，或狀態的變動時，可能會形成極大的危害。重複請求的後果在交易系統、售後維權，以及支付系統中尤爲嚴重。

前臺操做的抖動，快速操做，網絡通訊或者後端響應慢，都會增長後端重複處理的機率。

 前臺操做去抖動和防快速操做的措施，咱們首先會想到在前端作一層控制。當前端觸發操做時，或彈出確認界面，或disable入口並倒計時等等，此處不細表。

 但前端的限制僅能解決少部分問題，且不夠完全，後端自有的防重複處理措施必不可少，責無旁貸。

  嗯，囉嗦的緣由交代完畢，下面來說講具體的solution：

  咱們說是基於redis緩存的處理重複請求的方式，重複請求就是在很短的時間內發送屢次請求，這個時間是至關短的，以致於你進行數據庫查詢來驗證都無法取阻擋。這樣的話，咱們就可使用一個緩存的計數器來阻止這個問題的發生。在接口的開始，定義一個緩存計數器（該緩存的時間能夠是幾秒，幾十秒或者一兩分鐘，能完成短期內多個請求的這個短期的時間就行），同一個會員的每一個進來一個請求就將這個計數器+1（固然就是用會員的id+一些特定的字符串作key），對於大於1的請求不予受理。這樣在這個緩存進行的時間段內就能惟一確保只有一個。嗯，具體的實現方式就是這樣。（親測有效）

  下面推薦幾種處理方式（基本上仍是redis緩存機制最好，固然我也是主要從這裏借鑑的）：