大家好，我是狂聊。

自己最近負責的幾個接口，都涉及到了冪等性的操作，抽空總結了一下，這也是面試官比較愛問的問題。

一、什么是冪等?

看一下維基百科怎么說的：

冪等性：多次調用方法或者接口不會改變業(yè)務狀態(tài)，可以保證重復調用的結果和單次調用的結果一致。

二、使用冪等的場景

1、前端重復提交

用戶注冊，用戶創(chuàng)建商品等操作，前端都會提交一些數(shù)據(jù)給后臺服務，后臺需要根據(jù)用戶提交的數(shù)據(jù)在數(shù)據(jù)庫中創(chuàng)建記錄。如果用戶不小心多點了幾次，后端收到了好幾次提交，這時就會在數(shù)據(jù)庫中重復創(chuàng)建了多條記錄。這就是接口沒有冪等性帶來的 bug。

2、接口超時重試

對于給第三方調用的接口，有可能會因為網絡原因而調用失敗，這時，一般在設計的時候會對接口調用加上失敗重試的機制。如果第一次調用已經執(zhí)行了一半時，發(fā)生了網絡異常。這時再次調用時就會因為臟數(shù)據(jù)的存在而出現(xiàn)調用異常。

3、消息重復消費

在使用消息中間件來處理消息隊列，且手動 ack 確認消息被正常消費時。如果消費者突然斷開連接，那么已經執(zhí)行了一半的消息會重新放回隊列。

當消息被其他消費者重新消費時，如果沒有冪等性，就會導致消息重復消費時結果異常，如數(shù)據(jù)庫重復數(shù)據(jù)，數(shù)據(jù)庫數(shù)據(jù)沖突，資源重復等。

三、解決方案

1、token 機制實現(xiàn)

通過token 機制實現(xiàn)接口的冪等性,這是一種比較通用性的實現(xiàn)方法。

示意圖如下：

具體流程步驟：

客戶端會先發(fā)送一個請求去獲取 token，服務端會生成一個全局唯一的 ID 作為 token 保存在 redis 中，同時把這個 ID 返回給客戶端

客戶端第二次調用業(yè)務請求的時候必須攜帶這個 token

服務端會校驗這個 token，如果校驗成功，則執(zhí)行業(yè)務，并刪除 redis 中的 token

如果校驗失敗，說明 redis 中已經沒有對應的 token，則表示重復操作，直接返回指定的結果給客戶端

注意：

對 redis 中是否存在 token 以及刪除的代碼邏輯建議用 Lua 腳本實現(xiàn)，保證原子性

全局唯一 ID 可以用百度的 uid-generator、美團的 Leaf 去生成

2、基于 MySQL 實現(xiàn)

這種實現(xiàn)方式是利用 mysql 唯一索引的特性。

示意圖如下：

具體流程步驟：

建立一張去重表，其中某個字段需要建立唯一索引

客戶端去請求服務端，服務端會將這次請求的一些信息插入這張去重表中

因為表中某個字段帶有唯一索引，如果插入成功，證明表中沒有這次請求的信息，則執(zhí)行后續(xù)的業(yè)務邏輯

如果插入失敗，則代表已經執(zhí)行過當前請求，直接返回

3、基于 Redis 實現(xiàn)

這種實現(xiàn)方式是基于 SETNX 命令實現(xiàn)的

SETNX key value：將 key 的值設為 value ，當且僅當 key 不存在。若給定的 key 已經存在，則 SETNX 不做任何動作。

該命令在設置成功時返回 1，設置失敗時返回 0。

示意圖如下：

具體流程步驟：

客戶端先請求服務端，會拿到一個能代表這次請求業(yè)務的唯一字段

將該字段以 SETNX 的方式存入 redis 中，并根據(jù)業(yè)務設置相應的超時時間

如果設置成功，證明這是第一次請求，則執(zhí)行后續(xù)的業(yè)務邏輯

如果設置失敗，則代表已經執(zhí)行過當前請求，直接返回

總結

這幾種實現(xiàn)冪等的方式其實都是大同小異的，類似的還有使用狀態(tài)機、悲觀鎖、樂觀鎖的方式來實現(xiàn)，都是比較簡單的。

總之，當你去設計一個接口的時候，冪等都是首要考慮的問題，特別是當你負責設計轉賬、支付這種涉及到 money 的接口，你要格外注意嘍!

【編輯推薦】

【責任編輯：姜華 TEL：(010)68476606】

點贊 0

總結

以上是生活随笔為你收集整理的Mysql实现幂等_阿里面试官：接口的幂等性怎么设计？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。