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