搶微信紅包的時候我們都知道：一個紅包一旦你搶過之後，以後無論你點多少次都是一樣的結果。紅包會提示你已經搶過此紅包，而不會讓你再搶一次。 搶紅包介面就是一個非常典型的冪等介面，搶一次和搶多次具有一樣的效果。類似的介面在我們的開發過程中會有很多，比如在電商的下單過程中： > 訂單建立介面,第一次呼叫返回超時了，重試機制一般會再次呼叫這個介面，此時我們不能因為這個介面被調了兩次就建立兩個一樣的訂單； > 庫存扣減介面，支付介面也是類似的邏輯； 今天的文章就來講講什麼是介面的冪等性，並介紹幾種實現介面冪等性的方案。 ## 什麼是冪等 冪等原先是數學中的一個概念，表示進行1次變換和進行N次變換產生的效果相同。 當我們討論介面的冪等性時一般是在說：**以相同的請求呼叫這個介面一次和呼叫這個介面多次，對系統產生的影響是相同的**。如果一個介面滿足這個特性，那麼我們就說這個 介面是一個冪等介面。比如上面的搶紅包介面。 > PS：這邊順帶說下冪等和防止重複提交的區別。 >防止重複提交更多的是不讓使用者發起多次一樣的請求。比如說使用者線上購物下單時點了提交訂單按鈕，但是由於網路原因響應很慢，此時使用者比較心急多次點選了訂單提交按鈕。 >這種情況下就可能會造成多次下單。一般防止重複提交的方案有：將訂單按鈕置灰，跳轉到結果頁等。主要還是從客戶端的角度來解決這個問題。 >冪等更多的是在重複請求已經發生，或是無法避免的情況下，採取一定的技術手段讓這些重複請求不給系統帶來副作用。 ## 什麼情況下需要冪等 並不是所有介面都需要保證冪等性。以相同的請求呼叫這個介面一次或多次，需要給呼叫方返回一致的結果時，就要考慮將這個介面設計成冪等介面。 ## 實現冪等的幾種方案 在我們設計冪等介面時重點關注新增介面和更新介面。因為查詢和刪除操作天生是冪等的（根據id查詢和根據id刪除多次對系統的影響是一致的），不需要我們提供額外的 技術手段來保證冪等性。（？？） 對於新增和更新介面，大致有以下幾種方案可以保證介面冪等性。 ### 來源加序列號 這是一種比較好理解，通用的方案。 當呼叫介面時，引數中必須傳入`source`欄位和`seq`欄位（這邊舉了一個我們專案中的列子，其實並不一定要傳兩個欄位，傳一個唯一的序列號uuid也能達到一樣的效果）。服務端接收到請求，先判斷自己是否是一個冪等介面，如果不是冪等介面就正常處理請求。 如果是一個冪等介面，就將`source`和`seq`組成聯合主鍵去資料庫表中或者是Redis中查詢，如果沒有查詢到，說明沒處理過這個請求，然後正常處理請求就行了。處理完之後將處理結果和`source`和`seq`資訊一個存入資料庫或Redis中。 如果根據`source`和`seq`能查詢到，說明已經處理過這個請求了，直接將處理的結果返回即可。 我們發現這種方案非常簡單，而且易於理解，通用。但是如果請求量很大的話，存放請求記錄的表會很大，這個時候可以將一段時間之前的記錄刪除，以提升效能。 ### 唯一索引（唯一欄位） 這種方案適合用於執行新增操作的介面。 比如說新增使用者介面。我們將使用者表中的身份證欄位加上唯一索引。當同一個請求呼叫兩次時，我們可以先根據身份證欄位查詢下使用者是否存在，不存在的話再新增。存在的話就返回新增失敗。 或者直接新增也行，資料庫會拋異常，我們對異常處理返回前臺就行了。 > PS：大家可能會有一個疑問，我同一個請求呼叫兩次，第一返回新增成功，第二次返回失敗，返回的結果不同啊。這個介面還是冪等介面麼？ >這邊我要重申下概念，冪等強調的是介面一次呼叫和多次呼叫產生的效果是一樣的。這邊呼叫一次和呼叫多次都是新增了一個物件，所以還是滿足冪等的。 ### 樂觀鎖 這種方案適用於執行更新操作的介面。 樂觀鎖只是在更新資料那一刻鎖表，其他時間不鎖表，所以相對於悲觀鎖，效率更高。 我們一般通過資料庫來實現樂觀鎖，比較通用的做法是增加一個時間戳欄位。 ```sql update table_xxx set name=#name#, timestamp = now where id=#id# and timestamp=#timestamp# --這個值由前端到資料中查詢出來，再傳過來 ``` ## 參考 - [分散式系統的介面冪等性設計](https://www.cnblogs.com/jack87224088/p/8688948.html) - [如何避免下重複訂單](https://www.jianshu.com/p/e618cc818432) ## 公眾號推薦 歡迎大家關注我的微信公眾號，我會把好的部落格同步更新到公眾號上 ![](https://img2020.cnblogs.com/blog/1775037/202003/1775037-20200330153817909-78811