來，咱聊聊接口冪等性設(shè)計
逆鋒起筆關(guān)注后回復(fù)編程pdf
作者：pikaxiao blog.csdn.net/qq_36011946/article/details/104200262
冪等性設(shè)計
今天我們來聊聊接口的冪等性設(shè)計，所謂冪等，就是任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。 冪等性接口是指可以使用相同參數(shù)重復(fù)執(zhí)行，并能獲得相同結(jié)果的接口。這里就不展開數(shù)學(xué)中的定義了，有興趣的可以自行g(shù)oogle。
為什么接口需要冪等呢？
我們都知道，作為接口的調(diào)用方，對于接口調(diào)用的結(jié)果，一般會返回成功、失敗和超時。對于成功和失敗，都是明確的狀態(tài)，調(diào)用放可以根據(jù)結(jié)果做相應(yīng)的處理，但是對于超時，由于不確定是否成功請求了，作為調(diào)用方來說，所以一般都會選擇重試。而重試就會出現(xiàn)定義中描述的多次執(zhí)行。
可以從下面這個例子中加深一下理解：
-
創(chuàng)建訂單時，需要減庫存，如果減庫存接口超時了，調(diào)用方重新調(diào)用一次（無論是否成功的執(zhí)行了減庫存代碼），應(yīng)該要保證不會多減一次庫存。
要保證不會多件一次庫存，一般有兩種做法：
-
接口提供方需要提供相應(yīng)的查詢接口。調(diào)用方在超時后去查詢一下是否成功。是否多扣一次庫存掌握在調(diào)用方手里。如果接口是提供給第三方使用的，就會存在一定的風險。 -
接口支持冪等。這樣冪等的保證完全掌握在提供方自己手里，完全不用擔心。
全局ID
要讓接口支持冪等，要怎么做呢，你可能會想到在減庫存之前增加一次查詢，已經(jīng)減過的直接返回不就完事了么？這樣確實能達到目的，可是會額外多了一次查詢，有沒有什么更優(yōu)的方法呢？
要保證減庫存操作的唯一性，可以在接口上多加一個參數(shù)，這個參數(shù)必須全局唯一，數(shù)據(jù)庫設(shè)計表的時候這個字段要加上唯一索引，當多次保存相同數(shù)據(jù)的時候，數(shù)據(jù)庫就會報錯，這就證明了接口已經(jīng)成功調(diào)用過，可以直接返回。
那這個全局ID由誰來分配呢？
1.可以創(chuàng)建一個分配中心，由中心統(tǒng)一分配。
優(yōu)點：分配ID與業(yè)務(wù)集群解耦。
缺點：需要單獨維護分配中心，這個分配中心也必須做成高可用集群，增加維護成本。
2.集成在業(yè)務(wù)服務(wù)集群。
優(yōu)點：業(yè)務(wù)服務(wù)集群本來就是高可用的，無需提供額外保證。
缺點：分配ID與業(yè)務(wù)耦合（這其實沒什么影響），需要保證業(yè)務(wù)服務(wù)集群生成ID的唯一性。
一般來說，后者是比較好的方案，我們只要提供一個能在集群上生成全局唯一ID的算法即可。
除了保證全局唯一，最好具備以下特點（非必須）：
-
遞增，起碼保證每臺機器上的ID遞增。（保證數(shù)據(jù)庫性能） -
明確的規(guī)則，ID的各個位都有具體的定義。（方便追溯）
接下來就來說說現(xiàn)階段常用的全局ID算法。
UUID
UUID設(shè)計的目的就是讓分布式系統(tǒng)中的所有元素，都能有唯一的辨識信息，而不需要通過中央控制端來做辨識信息的指定。關(guān)于UUID的設(shè)計原理可自行Google。
優(yōu)點：實現(xiàn)簡單（大多數(shù)編程語言都集成到工具庫了），本地生成，性能好，擴展性高，不需要協(xié)定。
缺點：無法遞增（消耗數(shù)據(jù)庫性能）、UUID過長（消耗存儲空間）。
在中小型項目中，UUID會是不錯的選擇。為什么這么說呢？面對并發(fā)度不高的系統(tǒng)，數(shù)據(jù)庫性能一般不會達到瓶頸，所以說UUID是犧牲數(shù)據(jù)庫性能換取其優(yōu)點的一種選擇。
Snowflake
Snowflake是Twitter 的開源項目，它生成的ID是64bit的正整數(shù)，結(jié)構(gòu)如圖：
-
1bit：固定為0，二進制中最高位為符號位，0為整數(shù)，1位負數(shù)。所以固定為0表示生成的ID都為正數(shù) -
41bit：作為毫秒數(shù)，大約能用69年。 -
10bit：作為機器編號（5bit是數(shù)據(jù)中心ID，5bit為機器ID）。支持1204個實例。 -
12bit：序列號，一毫秒最多生成2^12=4096個。
優(yōu)點：遞增，且按時間有序。性能高，可根據(jù)情況分配bit。
缺點：依賴機器時鐘。在分布式系統(tǒng)中，各個機器上的時間不可能完全一樣，在同步各機器的時間時，可能會造成重復(fù)ID。
在高并發(fā)的業(yè)務(wù)下，Snowflake生成的整數(shù)ID的存儲和讀取性能都要優(yōu)于UUID。現(xiàn)階段國內(nèi)有很多基于Snowflake算法的特定實現(xiàn)，比如百度的UidGenerator。
關(guān)于Redis和MongoDB的設(shè)計這里就不展開了。畢竟要強依賴于存儲系統(tǒng)，添加了維護成本和風險點。
業(yè)務(wù)邏輯
正如我們前面講過的，要依賴于數(shù)據(jù)庫唯一性約束，當數(shù)據(jù)庫報唯一性沖突時，就說明這個求情已經(jīng)成功過了，不用再執(zhí)行，直接返回即可。
HTTP的冪等性
這里給出http請求的冪等性要求：
對于POST方法，可能會出現(xiàn)多次提交的問題，比如由于網(wǎng)絡(luò)不好等原因，造成請求超時，這是用戶再點一次提交按鈕。對此一般的冪等性解決方法如下：
在提交的表單隱藏一個全局ID，這個全局ID需要提前向后端獲取，提交的時候把這個ID一起提交過來，按照上圖所描述的業(yè)務(wù)邏輯，來支持冪等。后端成功以后前端跳轉(zhuǎn)，跳轉(zhuǎn)到GET請求，把剛才提交的數(shù)據(jù)展示出來。
小結(jié)
這篇講了冪等性設(shè)計的要點，并給出了設(shè)計方案，大家可根據(jù)具體情況選擇合適的方案。
逆鋒起筆是一個專注于程序員圈子的技術(shù)平臺，你可以收獲最新技術(shù)動態(tài)、最新內(nèi)測資格、BAT等大廠大佬的經(jīng)驗、增長自身、學(xué)習(xí)資料、職業(yè)路線、賺錢思維，微信搜索逆鋒起筆關(guān)注！
點贊是最大的支持
點「在看」的人都變好看了哦
