聊聊高并發下如何保證接口的冪等性？
前言
接口冪等性問題，對于開發人員來說，是一個跟語言無關的公共問題。本文分享了一些解決這類問題非常實用的辦法，絕大部分內容我在項目中實踐過的，給有需要的小伙伴一個參考。
不知道你有沒有遇到過這些場景：
- 有時我們在填寫某些form表單時，保存按鈕不小心快速點了兩次，表中竟然產生了兩條重復的數據，只是id不一樣。
- 我們在項目中為了解決接口超時問題，通常會引入了重試機制。第一次請求接口超時了，請求方沒能及時獲取返回結果(此時有可能已經成功了)，為了避免返回錯誤的結果(這種情況不可能直接返回失敗吧?)，于是會對該請求重試幾次，這樣也會產生重復的數據。
- mq消費者在讀取消息時，有時候會讀取到重復消息(至于什么原因這里先不說，有興趣的小伙伴，可以找我私聊)，如果處理不好，也會產生重復的數據。
沒錯，這些都是冪等性問題。
接口冪等性是指用戶對于同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點擊而產生了副作用。
這類問題多發于接口的：
- insert操作，這種情況下多次請求，可能會產生重復數據。
- update操作，如果只是單純的更新數據，比如：update user set status=1 where id=1，是沒有問題的。如果還有計算，比如：update user set status=status+1 where id=1，這種情況下多次請求，可能會導致數據錯誤。
那么我們要如何保證接口冪等性?本文將會告訴你答案。
1. insert前先select
通常情況下，在保存數據的接口中，我們為了防止產生重復數據，一般會在insert前，先根據name或code字段select一下數據。如果該數據已存在，則執行update操作，如果不存在，才執行 insert操作。
該方案可能是我們平時在防止產生重復數據時，使用最多的方案。但是該方案不適用于并發場景，在并發場景中，要配合其他方案一起使用，否則同樣會產生重復數據。我在這里提一下，是為了避免大家踩坑。
2. 加悲觀鎖
在支付場景中，用戶A的賬號余額有150元，想轉出100元，正常情況下用戶A的余額只剩50元。一般情況下，sql是這樣的：
- update user amount = amount-100 where id=123;
如果出現多次相同的請求，可能會導致用戶A的余額變成負數。這種情況，用戶A來可能要哭了。于此同時，系統開發人員可能也要哭了，因為這是很嚴重的系統bug。
為了解決這個問題，可以加悲觀鎖，將用戶A的那行數據鎖住，在同一時刻只允許一個請求獲得鎖，更新數據，其他的請求則等待。
通常情況下通過如下sql鎖住單行數據：
- select * from user id=123 for update;
具體流程如下：
具體步驟：
- 多個請求同時根據id查詢用戶信息。
- 判斷余額是否不足100，如果余額不足，則直接返回余額不足。
- 如果余額充足，則通過for update再次查詢用戶信息，并且嘗試獲取鎖。
- 只有第一個請求能獲取到行鎖，其余沒有獲取鎖的請求，則等待下一次獲取鎖的機會。
- 第一個請求獲取到鎖之后，判斷余額是否不足100，如果余額足夠，則進行update操作。
- 如果余額不足，說明是重復請求，則直接返回成功。
需要特別注意的是：如果使用的是mysql數據庫，存儲引擎必須用innodb，因為它才支持事務。此外，這里id字段一定要是主鍵或者唯一索引，不然會鎖住整張表。
悲觀鎖需要在同一個事務操作過程中鎖住一行數據，如果事務耗時比較長，會造成大量的請求等待，影響接口性能。此外，每次請求接口很難保證都有相同的返回值，所以不適合冪等性設計場景，但是在防重場景中是可以的使用的。在這里順便說一下，防重設計 和 冪等設計，其實是有區別的。防重設計主要為了避免產生重復數據，對接口返回沒有太多要求。而冪等設計除了避免產生重復數據之外，還要求每次請求都返回一樣的結果。3. 加樂觀鎖既然悲觀鎖有性能問題，為了提升接口性能，我們可以使用樂觀鎖。需要在表中增加一個timestamp或者version字段，這里以version字段為例。
在更新數據之前先查詢一下數據：
- select id,amount,version from user id=123;
如果數據存在，假設查到的version等于1，再使用id和version字段作為查詢條件更新數據：
- update user set amount=amount+100,version=version+1
- where id=123 and version=1;
更新數據的同時version+1，然后判斷本次update操作的影響行數，如果大于0，則說明本次更新成功，如果等于0，則說明本次更新沒有讓數據變更。
由于第一次請求version等于1是可以成功的，操作成功后version變成2了。這時如果并發的請求過來，再執行相同的sql：
- update user set amount=amount+100,version=version+1
- here id=123 and version=1;
該update操作不會真正更新數據，最終sql的執行結果影響行數是0，因為version已經變成2了，where中的version=1肯定無法滿足條件。但為了保證接口冪等性，接口可以直接返回成功，因為version值已經修改了，那么前面必定已經成功過一次，后面都是重復的請求。
具體流程如下：
具體步驟：
- 先根據id查詢用戶信息，包含version字段
- 根據id和version字段值作為where條件的參數，更新用戶信息，同時version+1
- 判斷操作影響行數，如果影響1行，則說明是一次請求，可以做其他數據操作。
- 如果影響0行，說明是重復請求，則直接返回成功。
4. 加唯一索引
絕大數情況下，為了防止重復數據的產生，我們都會在表中加唯一索引，這是一個非常簡單，并且有效的方案。
- alter table `order` add UNIQUE KEY `un_code` (`code`);
加了唯一索引之后，第一次請求數據可以插入成功。但后面的相同請求，插入數據時會報Duplicate entry '002' for key 'order.un_code異常，表示唯一索引有沖突。
雖說拋異常對數據來說沒有影響，不會造成錯誤數據。但是為了保證接口冪等性，我們需要對該異常進行捕獲，然后返回成功。
如果是java程序需要捕獲：DuplicateKeyException異常，如果使用了spring框架還需要捕獲：MySQLIntegrityConstraintViolationException異常。
具體流程圖如下：
具體步驟：
- 用戶通過瀏覽器發起請求，服務端收集數據。
- 將該數據插入mysql
- 判斷是否執行成功，如果成功，則操作其他數據(可能還有其他的業務邏輯)。
- 如果執行失敗，捕獲唯一索引沖突異常，直接返回成功。
5. 建防重表
有時候表中并非所有的場景都不允許產生重復的數據，只有某些特定場景才不允許。這時候，直接在表中加唯一索引，顯然是不太合適的。
針對這種情況，我們可以通過建防重表來解決問題。
該表可以只包含兩個字段：id 和 唯一索引，唯一索引可以是多個字段比如：name、code等組合起來的唯一標識，例如：susan_0001。
具體流程圖如下：
具體步驟：
- 用戶通過瀏覽器發起請求，服務端收集數據。
- 將該數據插入mysql防重表
- 判斷是否執行成功，如果成功，則做mysql其他的數據操作(可能還有其他的業務邏輯)。
- 如果執行失敗，捕獲唯一索引沖突異常，直接返回成功。
需要特別注意的是：防重表和業務表必須在同一個數據庫中，并且操作要在同一個事務中。
6. 根據狀態機
很多時候業務表是有狀態的，比如訂單表中有：1-下單、2-已支付、3-完成、4-撤銷等狀態。如果這些狀態的值是有規律的，按照業務節點正好是從小到大，我們就能通過它來保證接口的冪等性。
假如id=123的訂單狀態是已支付，現在要變成完成狀態。
- update `order` set status=3 where id=123 and status=2;
第一次請求時，該訂單的狀態是已支付，值是2，所以該update語句可以正常更新數據，sql執行結果的影響行數是1，訂單狀態變成了3。
后面有相同的請求過來，再執行相同的sql時，由于訂單狀態變成了3，再用status=2作為條件，無法查詢出需要更新的數據，所以最終sql執行結果的影響行數是0，即不會真正的更新數據。但為了保證接口冪等性，影響行數是0時，接口也可以直接返回成功。
具體流程圖如下：
具體步驟：
- 用戶通過瀏覽器發起請求，服務端收集數據。
- 根據id和當前狀態作為條件，更新成下一個狀態
- 判斷操作影響行數，如果影響了1行，說明當前操作成功，可以進行其他數據操作。
- 如果影響了0行，說明是重復請求，直接返回成功。
主要特別注意的是，該方案僅限于要更新的表有狀態字段，并且剛好要更新狀態字段的這種特殊情況，并非所有場景都適用。
7. 加分布式鎖
其實前面介紹過的加唯一索引或者加防重表，本質是使用了數據庫的分布式鎖，也屬于分布式鎖的一種。但由于數據庫分布式鎖的性能不太好，我們可以改用：redis或zookeeper。
鑒于現在很多公司分布式配置中心改用apollo或nacos，已經很少用zookeeper了，我們以redis為例介紹分布式鎖。
目前主要有三種方式實現redis的分布式鎖：
- setNx命令
- set命令
- Redission框架
每種方案各有利弊，具體實現細節我就不說了，有興趣的朋友可以加我微信找我私聊。
具體流程圖如下：
具體步驟：
- 用戶通過瀏覽器發起請求，服務端會收集數據，并且生成訂單號code作為唯一業務字段。
- 使用redis的set命令，將該訂單code設置到redis中，同時設置超時時間。
- 判斷是否設置成功，如果設置成功，說明是第一次請求，則進行數據操作。
- 如果設置失敗，說明是重復請求，則直接返回成功。
需要特別注意的是：分布式鎖一定要設置一個合理的過期時間，如果設置過短，無法有效的防止重復請求。如果設置過長，可能會浪費redis的存儲空間，需要根據實際業務情況而定。
8. 獲取token
除了上述方案之外，還有最后一種使用token的方案。該方案跟之前的所有方案都有點不一樣，需要兩次請求才能完成一次業務操作。
- 第一次請求獲取token
- 第二次請求帶著這個token，完成業務操作。
具體流程圖如下：
第一步，先獲取token。
第二步，做具體業務操作。
具體步驟：
- 用戶訪問頁面時，瀏覽器自動發起獲取token請求。
- 服務端生成token，保存到redis中，然后返回給瀏覽器。
- 用戶通過瀏覽器發起請求時，攜帶該token。
- 在redis中查詢該token是否存在，如果不存在，說明是第一次請求，做則后續的數據操作。
- 如果存在，說明是重復請求，則直接返回成功。
- 在redis中token會在過期時間之后，被自動刪除。
以上方案是針對冪等設計的。
如果是防重設計，流程圖要改改：
需要特別注意的是：token必須是全局唯一的。
