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