搶微信紅包的時候我們都知道：一個紅包一旦你搶過之后，以后無論你點多少次都是一樣的結果，紅包會提示你已經搶過此紅包，而不會讓你再搶一次，
搶紅包介面就是一個非常典型的冪等介面，搶一次和搶多次具有一樣的效果，類似的介面在我們的開發程序中會有很多，比如在電商的下單程序中：
訂單創建介面,第一次呼叫回傳超時了，重試機制一般會再次呼叫這個介面，此時我們不能因為這個介面被調了兩次就創建兩個一樣的訂單；
庫存扣減介面，支付介面也是類似的邏輯；
今天的文章就來講講什么是介面的冪等性，并介紹幾種實作介面冪等性的方案，
什么是冪等
冪等原先是數學中的一個概念，表示進行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# --這個值由前端到資料中查詢出來，再傳過來
參考
- 分布式系統的介面冪等性設計
- 如何避免下重復訂單
公眾號推薦
歡迎大家關注我的微信公眾號，我會把好的博客同步更新到公眾號上
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/5983.html
標籤：架構設計