實現接口冪等性的幾種方案
- 2020 年 3 月 30 日
- 筆記
搶微信紅包的時候我們都知道：一個紅包一旦你搶過之後，以後無論你點多少次都是一樣的結果。紅包會提示你已經搶過此紅包，而不會讓你再搶一次。
搶紅包接口就是一個非常典型的冪等接口，搶一次和搶多次具有一樣的效果。類似的接口在我們的開發過程中會有很多，比如在電商的下單過程中：
訂單創建接口,第一次調用返回超時了，重試機制一般會再次調用這個接口，此時我們不能因為這個接口被調了兩次就創建兩個一樣的訂單；
庫存扣減接口，支付接口也是類似的邏輯；
今天的文章就來講講什麼是接口的冪等性，並介紹幾種實現接口冪等性的方案。
什麼是冪等
冪等原先是數學中的一個概念，表示進行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# --這個值由前端到數據中查詢出來，再傳過來 參考
公眾號推薦
歡迎大家關注我的微信公眾號，我會把好的博客同步更新到公眾號上
