小米平板5 Pro 12.4簡(jiǎn)評(píng)：多專多能 兼顧影音娛樂(lè)的大屏利器
疫情帶來(lái)了網(wǎng)課，網(wǎng)課盤活了安卓平板，安卓平板市場(chǎng)雖然中途停滯了幾年，但好的一點(diǎn)就是停滯的這幾年行業(yè)又有了新的發(fā)展方向，例如超窄邊框、高刷新率、多攝鏡頭組合等，這就讓安卓
又是一個(gè)風(fēng)和日麗美好的一天，小貓戴著耳機(jī)，安逸地聽著音樂(lè)，擼著代碼，這種沒(méi)有會(huì)議的日子真的是巴適得板。
不料禍從天降，組長(zhǎng)火急火燎地跑過(guò)來(lái)找到了小貓?！翱炫挪橐幌拢壳坝蠥公司用戶反饋積分被多扣了”。
小貓回憶了一下“不對(duì)啊，這接口我也沒(méi)動(dòng)過(guò)啊，前幾天對(duì)外平臺(tái)的老六直接找我要個(gè)支付接口，我就給他了的，以前的代碼，我都沒(méi)有動(dòng)過(guò)的......”。
于是小貓一邊疑惑一邊翻看著以前的代碼，越看臉色越差......
小貓做的是一個(gè)標(biāo)準(zhǔn)的積分兌換商城，以前和客戶合作的時(shí)候，客戶直接用的是小貓單位自己定制的h5頁(yè)面。這次合作了一家公司有點(diǎn)特殊，由于公司想要定制化自己個(gè)性化的H5，加上本身A公司自己有開發(fā)能力，所以經(jīng)過(guò)討論就以接口的方式直接將相關(guān)接口給出去，A客戶H5開發(fā)完成之后自己來(lái)對(duì)接。
慢慢地，原因也水落石出，之前好好的業(yè)務(wù)一直沒(méi)有問(wèn)題是因?yàn)樯坛堑谋旧鞨5頁(yè)面做了防重復(fù)提交，由于量小，并且一般對(duì)接方式用的都是純H5，所以都沒(méi)有什么問(wèn)題，然后這次是直接將接口給出去了，完了接口居然沒(méi)有加冪等......
小貓?zhí)蓸專瑪?shù)據(jù)訂正當(dāng)然是少不了了，事故報(bào)告當(dāng)然也少不了了。
正所謂前人挖坑，后人遭殃，前人鍋后人背。
這個(gè)案例其實(shí)就是一個(gè)典型的接口冪等案例。那么老貓就和大家從以下幾個(gè)方面好好剖析一下接口冪等吧。
比較專業(yè)的術(shù)語(yǔ)：其任意多次執(zhí)行所產(chǎn)生的影響均與第一次執(zhí)行的影響相同。大白話：多次調(diào)用的情況下，接口最終得到的結(jié)果是一致的。
還有就是惡意攻擊了，有些業(yè)務(wù)接口做的比較粗糙，黑客找到漏洞之后會(huì)發(fā)起重復(fù)提交，這樣就會(huì)導(dǎo)致業(yè)務(wù)出現(xiàn)問(wèn)題。打個(gè)比方，老貓?jiān)?jīng)干過(guò)，鄰居小孩報(bào)名了一個(gè)畫畫比賽，估計(jì)是機(jī)構(gòu)培訓(xùn)發(fā)起的，功能做的也差，需要靠投票贏得某些禮品，然后老貓抓到接口信息之后就模擬投票進(jìn)行重復(fù)刷了投票。
首先我們說(shuō)是不是所有的接口都需要冪等？是不是加了冪等就好呢？顯然不是。因?yàn)榻涌趦绲鹊膶?shí)現(xiàn)某種意義上是要消耗系統(tǒng)性能的，我們沒(méi)有必要針對(duì)所有業(yè)務(wù)接口都加上冪等。
這個(gè)其實(shí)并不能做一個(gè)完全的定義說(shuō)哪個(gè)就不用冪等，因?yàn)楹芏鄷r(shí)候其實(shí)還是得結(jié)合業(yè)務(wù)邏輯一起看。但是其中也是有規(guī)律可循的。
既然我們說(shuō)冪等就是多次調(diào)用，接口最終得到結(jié)果一致，那么很顯然，查詢接口肯定是不要加冪等的，另外一些簡(jiǎn)單刪除數(shù)據(jù)的接口，無(wú)論是邏輯刪除還是物理刪除，看場(chǎng)景的情況下其實(shí)也不用加冪等。
但是大部分涉及到多表更新行為的接口，咱們最好還是得加上冪等。
前端防抖主要可以有兩種方案，一種是技術(shù)層面的，一種是產(chǎn)品層面的：
利用數(shù)據(jù)庫(kù)唯一索引。我們具體來(lái)看一下流程，咱們就用小貓遇到的例子。如下：
過(guò)程描述：
什么是樂(lè)觀鎖，它假設(shè)多用戶并發(fā)的事務(wù)在處理時(shí)不會(huì)彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分?jǐn)?shù)據(jù)。說(shuō)得直白一點(diǎn)樂(lè)觀鎖就是一個(gè)馬大哈?？偸羌僭O(shè)最好的情況，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，只在更新的時(shí)候會(huì)判斷一下在此期間別人有沒(méi)有去更新這個(gè)數(shù)據(jù)。
例如提交訂單的進(jìn)行支付扣款的時(shí)候，本來(lái)可能更新賬戶金額扣款的動(dòng)作是這樣的：
update Account set balance = balance-#{payAmount} where accountCode = #{accountCode}加上版本號(hào)之后，咱們的代碼就是這樣的：
update Account set balance = balance-#{payAmount},version=version +1 where accountCode = #{accountCode} and version = #{currVersion}這種情況下其實(shí)就要求客戶端每次在請(qǐng)求支付下單的時(shí)候都需要上層客戶端指定好當(dāng)前的版本信息。不過(guò)這種冪等的處理方式，老貓用的比較少。
悲觀鎖的話具有強(qiáng)烈的獨(dú)占和排他特性。大白話誰(shuí)都不信的主。所以我們就用select ... for update這樣的語(yǔ)法進(jìn)行行鎖，當(dāng)然老貓覺(jué)得單純的select ... for update只能解決同一時(shí)刻大并發(fā)的冪等，所以要保證單號(hào)重試這樣非并發(fā)的冪等請(qǐng)求還是得去校驗(yàn)當(dāng)前數(shù)據(jù)的狀態(tài)才行。就拿當(dāng)前的小貓遇到的場(chǎng)景來(lái)說(shuō)，流程如下：
悲觀鎖
begin; # 1.開始事務(wù)select * from order where order_code='666' for update # 查詢訂單，判斷狀態(tài),鎖住這條記錄if（status !=處理中）{ //非處理中狀態(tài)，直接返回； return ;}## 處理業(yè)務(wù)邏輯update order set status='完成' where order_code='666' # 更新完成update stock set num = num - 1 where spu='xxx' # 庫(kù)存更新commit; # 5.提交事務(wù)這里老貓一再想要強(qiáng)調(diào)的是在校驗(yàn)的時(shí)候還是得帶上本身的業(yè)務(wù)狀態(tài)去做校驗(yàn)，select ... for update并非萬(wàn)能冪等。
這個(gè)方案的本質(zhì)其實(shí)是引入了令牌桶的機(jī)制，當(dāng)提交訂單的時(shí)候，前端優(yōu)先會(huì)調(diào)用后端接口獲取一個(gè)token，token是由后端發(fā)放的。當(dāng)然token的生成方式有很多種，例如定時(shí)刷新令牌桶，或者定時(shí)生成令牌并放到令牌池中，當(dāng)然目的只有一個(gè)就是保住token的唯一性即可。
生成token之后將token放到redis中，當(dāng)然需要給token設(shè)置一個(gè)失效時(shí)間，超時(shí)的token也會(huì)被刪除。
當(dāng)后端接收到訂單提交的請(qǐng)求的時(shí)候，會(huì)先判斷token在緩存中是否存在，第一次請(qǐng)求的時(shí)候，token一定存在，也會(huì)正常返回結(jié)果，但是第二次攜帶同一個(gè)token的時(shí)候被拒絕了。
流程如下：
token機(jī)制
有個(gè)注意點(diǎn)大家可以思考一下：如果用戶用程序惡意刷單，同一個(gè)token發(fā)起了多次請(qǐng)求怎么辦？想要實(shí)現(xiàn)這個(gè)功能，就需要借助分布式鎖以及Lua腳本了，分布式鎖可以保證同一個(gè)token不能有多個(gè)請(qǐng)求同時(shí)過(guò)來(lái)訪問(wèn)，lua腳本保證從redis中獲取令牌->比對(duì)令牌->生成單號(hào)->刪除令牌這一系列行為的原子性。
現(xiàn)在很多的業(yè)務(wù)服務(wù)都是分布式系統(tǒng)，所以就拿分布式鎖來(lái)說(shuō)，關(guān)于分布式鎖，老貓?jiān)诖瞬蛔鲑樖觯袄县垖戇^(guò)redis的分布式鎖和實(shí)現(xiàn)，還有zk鎖和實(shí)現(xiàn)，具體可見鏈接：
當(dāng)然和上述的數(shù)據(jù)庫(kù)悲觀鎖類似，咱們的分布式鎖也只能保證同一個(gè)訂單在同一時(shí)間的處理。其次也是要去校訂單的狀態(tài)，防止其重復(fù)支付的，也就是說(shuō)，只要支付的訂單進(jìn)入后端，都要將原先的訂單修改為支付中，防止后續(xù)支付中斷之后的重復(fù)支付。
在上述小貓的流程中還沒(méi)有涉及到現(xiàn)金補(bǔ)充，如果涉及到現(xiàn)金補(bǔ)充的話，例如對(duì)接了微信或者支付寶的情況，還需要根據(jù)最終的支付回調(diào)結(jié)果來(lái)最終將訂單狀態(tài)進(jìn)行流轉(zhuǎn)成支付完成或者是支付失敗。
在我們?nèi)粘５拈_發(fā)中，一些重要的接口還是需要大家謹(jǐn)慎對(duì)待，即使是前任開發(fā)留下的接口，沒(méi)有任何改動(dòng)，當(dāng)有人咨詢的時(shí)候，其實(shí)就要好好去了解一下里面的實(shí)現(xiàn)，看看方案有沒(méi)有問(wèn)題，看看技術(shù)實(shí)現(xiàn)有沒(méi)有問(wèn)題，這應(yīng)該也是每一個(gè)程序員的基本素養(yǎng)。
另外的，在一些重要的接口上，尤其是資金相關(guān)的接口上，冪等真的是相當(dāng)?shù)闹匾Ｐ』锇閭儯銈冇X(jué)得呢？
本文鏈接：http://www.www897cc.com/showinfo-26-62793-0.html前任開發(fā)在代碼里下毒，支付下單居然沒(méi)加冪等
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)