介面的冪等性
介面冪等性問題，對於開發人員來說，是一個跟語言無關的公共問題。
本文分享了一些解決這類問題非常實用的辦法，絕大部分內容我在專案中實踐過的，給有需要的小夥伴一個參考。
不知道你有沒有遇到過這些場景：
1.有時我們在填寫某些form表單時，儲存按鈕不小心快速點了兩次，表中竟然產生了兩條重複的資料，只是id不一樣。
2.我們在專案中為了解決介面超時問題，通常會引入了重試機制。第一次請求介面超時了，請求方沒能及時獲取返回結果（此時有可能已經成功了），為了避免返回錯誤的結果（這種情況不可能直接返回失敗吧？），於是會對該請求重試幾次，這樣也會產生重複的資料。
3.mq消費者在讀取訊息時，有時候會讀取到重複訊息，如果處理不好，也會產生重複的資料。
這些都是冪等性問題。
介面冪等性是指使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了副作用。
這類問題多發於介面的：
insert操作，這種情況下多次請求，可能會產生重複資料。
update操作，如果只是單純的更新資料，比如：update user set status=1 where id=1，是沒有問題的。如果還有計算，比如：update user set status=status+1 where id=1，這種情況下多次請求，可能會導致資料錯誤。
那麼我們要如何保證介面冪等性？
一. insert前先select
通常情況下，在儲存資料的介面中，我們為了防止產生重複資料，一般會在insert前，先根據name或code欄位select一下資料。如果該資料已存在，則執行update操作，如果不存在，才執行insert操作。
該方案可能是我們平時在防止產生重複資料時，使用最多的方案。但是該方案不適用於併發場景，在併發場景中，要配合其他方案一起使用，否則同樣會產生重複資料。我在這裡提一下，是為了避免大家踩坑。
二.加樂觀鎖
需要在表中增加一個timestamp或者version欄位，這裡以version欄位為例。
在更新資料之前先查詢一下資料：
select id,amount,version from user id=123;
如果資料存在，假設查到的version等於1，再使用id和version欄位作為查詢條件更新資料：
update user set amount=amount+100,version=version+1where id=123 and version=1;
更新資料的同時version+1，然後判斷本次update操作的影響行數，如果大於0，則說明本次更新成功，如果等於0，則說明本次更新沒有讓資料變更。
由於第一次請求version等於1是可以成功的，操作成功後version變成2了。這時如果併發的請求過來，再執行相同的sql：
update user set amount=amount+100,version=version+1where id=123 and version=1;
該update操作不會真正更新資料，最終sql的執行結果影響行數是0，因為version已經變成2了，where中的version=1肯定無法滿足條件。但為了保證介面冪等性，介面可以直接返回成功，因為version值已經修改了，那麼前面必定已經成功過一次，後面都是重複的請求。
具體流程如下：
1.先根據id查詢使用者資訊，包含version欄位
2.根據id和version欄位值作為where條件的引數，更新使用者資訊，同時version+1
3.判斷操作影響行數，如果影響1行，則說明是一次請求，可以做其他資料操作。
4.如果影響0行，說明是重複請求，則直接返回成功。
三.絕大數情況下，為了防止重複資料的產生，我們都會在表中加唯一索引，這是一個非常簡單，並且有效的方案。
alter table order add UNIQUE KEY un_code (code);
加了唯一索引之後，第一次請求資料可以插入成功。但後面的相同請求，插入資料時會報Duplicate entry '002' for key 'order.un_code異常，表示唯一索引有衝突。
雖說拋異常對資料來說沒有影響，不會造成錯誤資料。但是為了保證介面冪等性，我們需要對該異常進行捕獲，然後返回成功。
如果是java程式需要捕獲：DuplicateKeyException異常，如果使用了spring框架還需要捕獲：MySQLIntegrityConstraintViolationException異常。
具體流程圖如下：
具體步驟：
1.使用者通過瀏覽器發起請求，服務端收集資料。
2.將該資料插入mysql
3.判斷是否執行成功，如果成功，則操作其他資料（可能還有其他的業務邏輯）。
4.如果執行失敗，捕獲唯一索引衝突異常，直接返回成功。
四.建防重表
有時候表中並非所有的場景都不允許產生重複的資料，只有某些特定場景才不允許。這時候，直接在表中加唯一索引，顯然是不太合適的。
針對這種情況，我們可以通過建防重表來解決問題。
該表可以只包含兩個欄位：id和唯一索引，唯一索引可以是多個欄位比如：name、code等組合起來的唯一標識，例如：susan_0001。
具體流程圖如下：
具體步驟：
1.使用者通過瀏覽器發起請求，服務端收集資料。
2.將該資料插入mysql防重表
3.判斷是否執行成功，如果成功，則做mysql其他的資料操作（可能還有其他的業務邏輯）。
4.如果執行失敗，捕獲唯一索引衝突異常，直接返回成功。
五.根據狀態機
很多時候業務表是有狀態的，比如訂單表中有：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時，介面也可以直接返回成功。
具體流程圖如下：
具體步驟：
1.使用者通過瀏覽器發起請求，服務端收集資料。
2.根據id和當前狀態作為條件，更新成下一個狀態
3.判斷操作影響行數，如果影響了1行，說明當前操作成功，可以進行其他資料操作。
4.如果影響了0行，說明是重複請求，直接返回成功。
主要特別注意的是，該方案僅限於要更新的表有狀態欄位，並且剛好要更新狀態欄位的這種特殊情況，並非所有場景都適用。
六.加分散式鎖
其實前面介紹過的加唯一索引或者加防重表，本質是使用了資料庫的分散式鎖，也屬於分散式鎖的一種。但由於資料庫分散式鎖的效能不太好，我們可以改用：redis或zookeeper。
鑑於現在很多公司分散式配置中心改用apollo或nacos，已經很少用zookeeper了，我們以redis為例介紹分散式鎖。
目前主要有三種方式實現redis的分散式鎖：
1.setNx命令 2.set命令 3.Redission框架
每種方案各有利弊，具體實現細節我就不說了
具體流程圖如下：
具體步驟：
1.使用者通過瀏覽器發起請求，服務端會收集資料，並且生成訂單號code作為唯一業務欄位。
2.使用redis的set命令，將該訂單code設定到redis中，同時設定超時時間。
3.判斷是否設定成功，如果設定成功，說明是第一次請求，則進行資料操作。
4.如果設定失敗，說明是重複請求，則直接返回成功。
需要特別注意的是：分散式鎖一定要設定一個合理的過期時間，如果設定過短，無法有效的防止重複請求。如果設定過長，可能會浪費redis的儲存空間，需要根據實際業務情況而定。
七： 獲取token
除了上述方案之外，還有最後一種使用token的方案。該方案跟之前的所有方案都有點不一樣，需要兩次請求才能完成一次業務操作。
1.第一次請求獲取token
2.第二次請求帶著這個token，完成業務操作。
具體流程圖如下：
第一步，先獲取token。
第二步，做具體業務操作。
具體步驟：
1.使用者訪問頁面時，瀏覽器自動發起獲取token請求。
2.服務端生成token，儲存到redis中，然後返回給瀏覽器。
3.使用者通過瀏覽器發起請求時，攜帶該token。
4.在redis中查詢該token是否存在，如果不存在，說明是第一次請求，做則後續的資料操作。
5.如果存在，說明是重複請求，則直接返回成功。
6.在redis中token會在過期時間之後，被自動刪除。