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