目錄
[TOC]
前言
????今天的主題：接口冪等性的解決方案怎披。本來是想把對象的存儲過程和內存布局肝出來的，但是臨時產生了變化瓶摆，哈哈凉逛，這部分內容我們留在下一期吧，有句話說的好群井，好事多磨状飞，對吧。</br>
????在實際項目開發(fā)中接口是我們在開發(fā)中經常接觸到的书斜，而且是經常經常要寫诬辈，每一個項目可能都會伴隨著大量的接口開發(fā)，在moon來涂鴉的這幾個月荐吉，基本上就是在與接口作斗爭了焙糟，新需求除了業(yè)務相關就是設計表和接口編寫了。</br>
????當然稍坯，在接口設計中我們要考慮很多問題酬荞，安全性，格式瞧哟，設計等等混巧，今天我們先來聊聊，在高并發(fā)環(huán)境下勤揩，接口冪等性的解決方案有哪些咧党。
正文
1 接口冪等性
???? 就是說在多次相同的操作下保證最終的結果是一致的。
????其實這個概念還是比較簡單的陨亡，很容易理解傍衡，那我們思考一個問題深员，如果不保證接口冪等性會有什么問題？
1.1 案例
????我們簡單的舉個例子蛙埂，現(xiàn)在有一個接口倦畅，提供了轉賬的功能，a要給b轉賬1000元绣的，正常情況下我們接口一次性就調用成功了叠赐，但是卻因為網絡抖動等其它原因沒有成功，于是就開始不停的重試屡江，突然網絡好了芭概，但是這時卻連續(xù)發(fā)出去了三個請求，但是這個接口沒有保證冪等性惩嘉，于是從結果上來看就是a給b轉了3000元罢洲，這顯然是程序業(yè)務邏輯上不能接受的(其實moon可以當b的)。
2 解決方案
2.1 token機制
????token機制其實是比較簡單的文黎，我們先來簡單的說一下流程惹苗。</br>
- 首先客戶端先請求服務端，服務端生成token耸峭，每次請求生成的都是一個新的token(這個token一定要設置超時時間)鸽粉，將token存入redis當中，然后將token返回給客戶端抓艳。
- 客戶端攜帶剛剛返回的token請求服務端做業(yè)務請求。
- 服務端收到請求帚戳，做判斷玷或。
- 如果token在redis中，則直接刪除該token片任，然后繼續(xù)做業(yè)務請求偏友。
- 如果token不在redis中，代表已經執(zhí)行過當前業(yè)務了对供，則不執(zhí)行業(yè)務位他。
????圖示如下：
????token機制實現(xiàn)方式還是比較簡單的，但是其實對于我們某些響應速度要求很高的業(yè)務不太友好产场，缺點就是需要多一次請求獲取token的過程鹅髓。
????正常來說是每次請都會生成一個新的token，如果有極限情況下京景，有兩個請求都帶著相同的token進來窿冯，會存在都走入判斷是否存在的過程，可能都會同時查到存在确徙，這樣也會有問題醒串，針對這種情況执桌，我們可以在刪除前判斷下是否存在，存在就刪除芜赌，為了保證原子性仰挣，這部分邏輯建議使用lua腳本完成。
2.2 去重表
????去重表的機制是根據mysql唯一索引的特性來的缠沈，我們先來說下它的流程：
- 首先客戶端先請求服務端膘壶，服務端先將這次的請求信息存入一張mysql的去重表中，這張表要根據這次請求的其中某個特殊字段建立唯一索引博烂，或者主鍵索引香椎。
-
判斷是否插入成功
- 如果插入成功，則繼續(xù)做后續(xù)業(yè)務請求禽篱。
- 如果插入失敗畜伐，則代表已經執(zhí)行過當前請求。
????圖示如下：
????去重表機制的問題有兩點：
- 1.mysql容錯性躺率，也就是mysql本身如果不是高可用的那么業(yè)務可能會受到影響：
- 2.既然是唯一索引玛界，自然在寫表的時候就沒有辦法用到changbuffer，每次都要從磁盤查出來判斷再寫入悼吱，對于一個高并發(fā)的接口來說慎框，這些都是需要考慮的因素。
2.3 redis 的 SETNX鍵值
????過程如下：
- 首先客戶端先請求服務端后添，服務端將能代表這次請求業(yè)務的唯一字段以 SETNX 的方式存入redis笨枯，并設置超時時間，超時時間可以根據業(yè)務權衡遇西。
-
判斷是否插入成功
- 如果插入成功馅精，則繼續(xù)做后續(xù)業(yè)務請求。
- 如果插入失敗粱檀，則代表已經執(zhí)行過當前請求洲敢。
????這里我們是利用了redis setnx 的特性來完成的。</br>
????setnx:只在鍵key不存在的情況下茄蚯，將鍵key的值設置為value压彭。若鍵key已經存在，則SETNX命令不做任何動作渗常。命令在設置成功時返回1壮不，設置失敗時返回0。
????圖示如下：
????這種方案可以說是針對上一個方案改進的凳谦，效率也會提高很多忆畅。
2.4 狀態(tài)機冪
????這種機制適用于有不同狀態(tài)的業(yè)務，moon的上一家公司就是這樣做的。
????我們的訂單系統(tǒng)家凯，一條訂單會有多個狀態(tài)缓醋，如：待付款，鎖定绊诲，已付款等狀態(tài)送粱，而這些狀態(tài)都是有流程和邏輯的，我們可以根據這個狀態(tài)判斷是否執(zhí)行后續(xù)業(yè)務操作掂之。
2.5 樂觀鎖(更新操作)
????就是數據庫中增加版本號字段抗俄，每次更新根據版本號來判斷
????過程如下：
- 首先客戶端先請求服務端，先查詢出當前的version版本世舰。
- select version from .. where ..
- 根據version版本來做sql操作
- UPDATE .. SET ... version=(version+1) WHERE .. AND version=version;
????這個圖示我就不再畫了动雹，還是比較簡單的
2.6 悲觀鎖(更新操作)
????假設每一次拿數據，都有認為會被修改跟压，所以給數據庫的行上鎖胰蝠，也是基于數據庫特性來完成。
???? 當數據庫執(zhí)行select for update時會獲取被select中的數據行的行鎖震蒋，因此其他并發(fā)執(zhí)行的select for update如果試圖選中同一行則會發(fā)生排斥（需要等待行鎖被釋放）茸塞，因此達到鎖的效果。
START TRANSACTION; # 開啟事務
SELETE * FROM TABLE WHERE .. FOR UPDATE;
UPDATE TABLE SET ... WHERE ..;
COMMIT; # 提交事務
結語
????關于接口冪等性這部分內容查剖，解決方案其實大同小異钾虐，很多方式的原理都是一樣的，更多的其實都是在業(yè)務鏈路中去過濾笋庄，也會有很多是有消息中間件去解決的效扫，默認在中間件這一層就直接過濾掉了，當然每種方式都有各自的優(yōu)點和缺點直砂，需要結合當前的業(yè)務去選擇荡短，今天的文章內容，你get到了嗎哆键？
????我是moon，下一篇瘦锹，真的要講jvm了~ 下次見~
