[前言]

接口冪等性問題董朝，對于開發(fā)人員來說楼入，是一個跟語言無關(guān)的公共問題。本文分享了一些解決這類問題非常實用的辦法愧薛，絕大部分內(nèi)容我在項目中實踐過的毫炉，給有需要的小伙伴一個參考府瞄。

不知道你有沒有遇到過這些場景：

1. 有時我們在填寫某些form表單時，保存按鈕不小心快速點了兩次碘箍，表中竟然產(chǎn)生了兩條重復(fù)的數(shù)據(jù)遵馆，只是id不一樣。
2. 我們在項目中為了解決接口超時問題丰榴，通常會引入了重試機制货邓。第一次請求接口超時了，請求方?jīng)]能及時獲取返回結(jié)果（此時有可能已經(jīng)成功了）四濒，為了避免返回錯誤的結(jié)果（這種情況不可能直接返回失敗吧换况？），于是會對該請求重試幾次盗蟆，這樣也會產(chǎn)生重復(fù)的數(shù)據(jù)戈二。
3. mq消費者在讀取消息時，有時候會讀取到重復(fù)消息（至于什么原因這里先不說喳资，有興趣的小伙伴觉吭，可以找我私聊），如果處理不好仆邓，也會產(chǎn)生重復(fù)的數(shù)據(jù)鲜滩。

沒錯，這些都是冪等性問題节值。

接口冪等性是指用戶對于同一操作發(fā)起的一次請求或者多次請求的結(jié)果是一致的徙硅，不會因為多次點擊而產(chǎn)生了副作用。

這類問題多發(fā)于接口的：

• insert操作搞疗，這種情況下多次請求嗓蘑，可能會產(chǎn)生重復(fù)數(shù)據(jù)。
• update操作，如果只是單純的更新數(shù)據(jù)桩皿，比如：update user set status=1 where id=1豌汇，是沒有問題的。如果還有計算业簿，比如：update user set status=status+1 where id=1，這種情況下多次請求阳懂，可能會導(dǎo)致數(shù)據(jù)錯誤梅尤。

那么我們要如何保證接口冪等性？本文將會告訴你答案岩调。

[1. insert前先select]

通常情況下巷燥，在保存數(shù)據(jù)的接口中，我們?yōu)榱朔乐巩a(chǎn)生重復(fù)數(shù)據(jù)号枕，一般會在insert前缰揪，先根據(jù)name或code字段select一下數(shù)據(jù)。如果該數(shù)據(jù)已存在葱淳，則執(zhí)行update操作钝腺，如果不存在，才執(zhí)行 insert操作赞厕。

圖片

該方案可能是我們平時在防止產(chǎn)生重復(fù)數(shù)據(jù)時艳狐，使用最多的方案。但是該方案不適用于并發(fā)場景皿桑，在并發(fā)場景中毫目，要配合其他方案一起使用，否則同樣會產(chǎn)生重復(fù)數(shù)據(jù)诲侮。我在這里提一下镀虐，是為了避免大家踩坑。

[2. 加悲觀鎖]

在支付場景中沟绪，用戶A的賬號余額有150元刮便，想轉(zhuǎn)出100元，正常情況下用戶A的余額只剩50元绽慈。一般情況下诺核，sql是這樣的：

update user amount = amount-100 where id=123;

如果出現(xiàn)多次相同的請求，可能會導(dǎo)致用戶A的余額變成負(fù)數(shù)久信。這種情況窖杀，用戶A來可能要哭了。于此同時裙士，系統(tǒng)開發(fā)人員可能也要哭了入客，因為這是很嚴(yán)重的系統(tǒng)bug。

為了解決這個問題，可以加悲觀鎖桌硫，將用戶A的那行數(shù)據(jù)鎖住夭咬，在同一時刻只允許一個請求獲得鎖，更新數(shù)據(jù)铆隘，其他的請求則等待卓舵。

通常情況下通過如下sql鎖住單行數(shù)據(jù)：

select * from user id=123 for update;

具體流程如下：

具體步驟：

1. 多個請求同時根據(jù)id查詢用戶信息。
2. 判斷余額是否不足100膀钠，如果余額不足掏湾，則直接返回余額不足。
3. 如果余額充足肿嘲，則通過for update再次查詢用戶信息融击，并且嘗試獲取鎖。
4. 只有第一個請求能獲取到行鎖雳窟，其余沒有獲取鎖的請求尊浪，則等待下一次獲取鎖的機會。
5. 第一個請求獲取到鎖之后封救，判斷余額是否不足100拇涤，如果余額足夠，則進行update操作誉结。
6. 如果余額不足工育，說明是重復(fù)請求，則直接返回成功搓彻。

需要特別注意的是：如果使用的是mysql數(shù)據(jù)庫如绸，存儲引擎必須用innodb，因為它才支持事務(wù)旭贬。此外怔接，這里id字段一定要是主鍵或者唯一索引，不然會鎖住整張表稀轨。

悲觀鎖需要在同一個事務(wù)操作過程中鎖住一行數(shù)據(jù)扼脐，如果事務(wù)耗時比較長，會造成大量的請求等待奋刽，影響接口性能瓦侮。

此外，每次請求接口很難保證都有相同的返回值佣谐，所以不適合冪等性設(shè)計場景肚吏，但是在防重場景中是可以的使用的。

在這里順便說一下狭魂，防重設(shè)計 和 冪等設(shè)計罚攀，其實是有區(qū)別的党觅。防重設(shè)計主要為了避免產(chǎn)生重復(fù)數(shù)據(jù)，對接口返回沒有太多要求斋泄。而冪等設(shè)計除了避免產(chǎn)生重復(fù)數(shù)據(jù)之外杯瞻，還要求每次請求都返回一樣的結(jié)果。

[3. 加樂觀鎖]

既然悲觀鎖有性能問題炫掐，為了提升接口性能魁莉，我們可以使用樂觀鎖。需要在表中增加一個timestamp或者version字段募胃，這里以version字段為例旗唁。

在更新數(shù)據(jù)之前先查詢一下數(shù)據(jù)：

select id,amount,version from user id=123;

如果數(shù)據(jù)存在，假設(shè)查到的version等于1摔认，再使用id和version字段作為查詢條件更新數(shù)據(jù)：

update user set amount=amount+100,version=version+1where id=123 and version=1;

更新數(shù)據(jù)的同時version+1逆皮，然后判斷本次update操作的影響行數(shù)宅粥，如果大于0参袱，則說明本次更新成功，如果等于0秽梅，則說明本次更新沒有讓數(shù)據(jù)變更抹蚀。

由于第一次請求version等于1是可以成功的，操作成功后version變成2了企垦。這時如果并發(fā)的請求過來环壤，再執(zhí)行相同的sql：

update user set amount=amount+100,version=version+1where id=123 and version=1;

該update操作不會真正更新數(shù)據(jù)，最終sql的執(zhí)行結(jié)果影響行數(shù)是0钞诡，因為version已經(jīng)變成2了郑现，where中的version=1肯定無法滿足條件。但為了保證接口冪等性荧降，接口可以直接返回成功接箫，因為version值已經(jīng)修改了，那么前面必定已經(jīng)成功過一次朵诫，后面都是重復(fù)的請求辛友。

具體步驟：

1. 先根據(jù)id查詢用戶信息，包含version字段
2. 根據(jù)id和version字段值作為where條件的參數(shù)剪返，更新用戶信息废累，同時version+1
3. 判斷操作影響行數(shù)，如果影響1行脱盲，則說明是一次請求邑滨，可以做其他數(shù)據(jù)操作。
4. 如果影響0行钱反，說明是重復(fù)請求驼修，則直接返回成功殿遂。

[4. 加唯一索引]

絕大數(shù)情況下，為了防止重復(fù)數(shù)據(jù)的產(chǎn)生乙各，我們都會在表中加唯一索引墨礁，這是一個非常簡單，并且有效的方案耳峦。

alter tableorderadd UNIQUE KEYun_code(code);

加了唯一索引之后恩静，第一次請求數(shù)據(jù)可以插入成功。但后面的相同請求蹲坷，插入數(shù)據(jù)時會報Duplicate entry '002' for key 'order.un_code異常驶乾，表示唯一索引有沖突。

雖說拋異常對數(shù)據(jù)來說沒有影響循签，不會造成錯誤數(shù)據(jù)级乐。但是為了保證接口冪等性，我們需要對該異常進行捕獲县匠，然后返回成功风科。

如果是java程序需要捕獲：DuplicateKeyException異常，如果使用了spring框架還需要捕獲：MySQLIntegrityConstraintViolationException異常乞旦。

具體流程圖如下：

具體步驟：

1. 用戶通過瀏覽器發(fā)起請求贼穆，服務(wù)端收集數(shù)據(jù)。
2. 將該數(shù)據(jù)插入mysql
3. 判斷是否執(zhí)行成功兰粉，如果成功故痊，則操作其他數(shù)據(jù)（可能還有其他的業(yè)務(wù)邏輯）。
4. 如果執(zhí)行失敗玖姑，捕獲唯一索引沖突異常愕秫，直接返回成功。

[5. 建防重表]

有時候表中并非所有的場景都不允許產(chǎn)生重復(fù)的數(shù)據(jù)焰络，只有某些特定場景才不允許戴甩。這時候，直接在表中加唯一索引舔琅，顯然是不太合適的等恐。

針對這種情況，我們可以通過建防重表來解決問題备蚓。

該表可以只包含兩個字段：id 和 唯一索引课蔬，唯一索引可以是多個字段比如：name、code等組合起來的唯一標(biāo)識郊尝，例如：susan_0001二跋。

具體流程圖如下：

具體步驟：

1. 用戶通過瀏覽器發(fā)起請求，服務(wù)端收集數(shù)據(jù)流昏。
2. 將該數(shù)據(jù)插入mysql防重表
3. 判斷是否執(zhí)行成功扎即，如果成功吞获，則做mysql其他的數(shù)據(jù)操作（可能還有其他的業(yè)務(wù)邏輯）。
4. 如果執(zhí)行失敗谚鄙，捕獲唯一索引沖突異常各拷，直接返回成功。

需要特別注意的是：防重表和業(yè)務(wù)表必須在同一個數(shù)據(jù)庫中闷营，并且操作要在同一個事務(wù)中烤黍。

[6. 根據(jù)狀態(tài)機]

很多時候業(yè)務(wù)表是有狀態(tài)的，比如訂單表中有：1-下單傻盟、2-已支付速蕊、3-完成、4-撤銷等狀態(tài)娘赴。如果這些狀態(tài)的值是有規(guī)律的规哲，按照業(yè)務(wù)節(jié)點正好是從小到大，我們就能通過它來保證接口的冪等性诽表。

假如id=123的訂單狀態(tài)是已支付唉锌，現(xiàn)在要變成完成狀態(tài)。

updateorderset status=3 where id=123 and status=2;

第一次請求時关顷，該訂單的狀態(tài)是已支付糊秆，值是2武福，所以該update語句可以正常更新數(shù)據(jù)议双，sql執(zhí)行結(jié)果的影響行數(shù)是1，訂單狀態(tài)變成了3捉片。

后面有相同的請求過來平痰，再執(zhí)行相同的sql時，由于訂單狀態(tài)變成了3伍纫，再用status=2作為條件宗雇，無法查詢出需要更新的數(shù)據(jù)，所以最終sql執(zhí)行結(jié)果的影響行數(shù)是0莹规，即不會真正的更新數(shù)據(jù)赔蒲。但為了保證接口冪等性，影響行數(shù)是0時良漱，接口也可以直接返回成功舞虱。

具體流程圖如下：

具體步驟：

1. 用戶通過瀏覽器發(fā)起請求，服務(wù)端收集數(shù)據(jù)母市。
2. 根據(jù)id和當(dāng)前狀態(tài)作為條件矾兜，更新成下一個狀態(tài)
3. 判斷操作影響行數(shù)，如果影響了1行患久，說明當(dāng)前操作成功椅寺，可以進行其他數(shù)據(jù)操作浑槽。
4. 如果影響了0行，說明是重復(fù)請求返帕，直接返回成功桐玻。

主要特別注意的是，該方案僅限于要更新的表有狀態(tài)字段荆萤，并且剛好要更新狀態(tài)字段的這種特殊情況畸冲，并非所有場景都適用。

[7. 加分布式鎖]

其實前面介紹過的加唯一索引或者加防重表观腊，本質(zhì)是使用了數(shù)據(jù)庫的分布式鎖邑闲，也屬于分布式鎖的一種。但由于數(shù)據(jù)庫分布式鎖的性能不太好梧油，我們可以改用：redis或zookeeper苫耸。

鑒于現(xiàn)在很多公司分布式配置中心改用apollo或nacos，已經(jīng)很少用zookeeper了儡陨，我們以redis為例介紹分布式鎖褪子。

目前主要有三種方式實現(xiàn)redis的分布式鎖：

1. setNx命令
2. set命令
3. Redission框架

每種方案各有利弊，具體實現(xiàn)細節(jié)我就不說了骗村，有興趣的朋友可以加我微信找我私聊嫌褪。

具體流程圖如下：

具體步驟：

1. 用戶通過瀏覽器發(fā)起請求，服務(wù)端會收集數(shù)據(jù)胚股，并且生成訂單號code作為唯一業(yè)務(wù)字段笼痛。
2. 使用redis的set命令，將該訂單code設(shè)置到redis中琅拌，同時設(shè)置超時時間缨伊。
3. 判斷是否設(shè)置成功，如果設(shè)置成功进宝，說明是第一次請求刻坊，則進行數(shù)據(jù)操作。
4. 如果設(shè)置失敗党晋，說明是重復(fù)請求谭胚，則直接返回成功。

需要特別注意的是：分布式鎖一定要設(shè)置一個合理的過期時間未玻，如果設(shè)置過短灾而，無法有效的防止重復(fù)請求。如果設(shè)置過長深胳，可能會浪費redis的存儲空間绰疤，需要根據(jù)實際業(yè)務(wù)情況而定。

[8. 獲取token]

除了上述方案之外舞终，還有最后一種使用token的方案轻庆。該方案跟之前的所有方案都有點不一樣癣猾，需要兩次請求才能完成一次業(yè)務(wù)操作。

1. 第一次請求獲取token
2. 第二次請求帶著這個token余爆，完成業(yè)務(wù)操作纷宇。

具體流程圖如下：

第一步，先獲取token蛾方。

第二步像捶，做具體業(yè)務(wù)操作。

具體步驟：

1. 用戶訪問頁面時桩砰，瀏覽器自動發(fā)起獲取token請求拓春。
2. 服務(wù)端生成token，保存到redis中亚隅，然后返回給瀏覽器硼莽。
3. 用戶通過瀏覽器發(fā)起請求時，攜帶該token煮纵。
4. 在redis中查詢該token是否存在懂鸵，如果不存在，說明是第一次請求行疏，做則后續(xù)的數(shù)據(jù)操作匆光。
5. 如果存在，說明是重復(fù)請求酿联，則直接返回成功终息。
6. 在redis中token會在過期時間之后，被自動刪除货葬。

以上方案是針對冪等設(shè)計的采幌。

如果是防重設(shè)計劲够，流程圖要改改：

圖片

需要特別注意的是：token必須是全局唯一的震桶。