6月安卓手機(jī)性能榜：vivo/iQOO霸占旗艦排行榜前三
2023年上半年已經(jīng)正式過去了，我們也迎來了安兔兔V10版本，在新的驍龍8Gen3和天璣9300發(fā)布之前，性能榜的榜單大體會以驍龍8Gen2和天璣9200+為主，至于那顆3.36GHz的驍龍8Gen2領(lǐng)先
碼猿慢病云管理系統(tǒng)中其實(shí)高并發(fā)的場景不是很多，沒有必要每個接口都去考慮并發(fā)高的場景，比如添加住院患者的這個接口，具體的業(yè)務(wù)代碼就不貼了，業(yè)務(wù)偽代碼如下：
圖片
上述代碼有問題嗎？誰能說有問題？一般情況下是沒什么問題，但是在高并發(fā)的場景下肯定是存在問題，為什么？
因?yàn)橛惺聞?wù)的隔離性，step1這個階段對住院號的校驗(yàn)肯定是存在問題的，在高并發(fā)的場景下無法保證這里的校驗(yàn)一定準(zhǔn)確。
其實(shí)這個接口的并發(fā)并不高，在碼猿慢病云管理系統(tǒng)中一般不會出現(xiàn)這種問題，那么什么時(shí)候會出現(xiàn)呢？
醫(yī)院中大部分是內(nèi)網(wǎng)+外網(wǎng)，如果由于網(wǎng)絡(luò)的抖動，系統(tǒng)請求響應(yīng)的時(shí)間延遲，這樣會導(dǎo)致醫(yī)護(hù)操作時(shí)會出現(xiàn)重復(fù)點(diǎn)擊的情況，比如1秒中之內(nèi)由于第一次點(diǎn)添加患者這個按鈕沒反應(yīng)，往往護(hù)士都會重復(fù)點(diǎn)擊，這種情況下是會出現(xiàn)問題。
這里我們就暫且不談對單個接口的冪等優(yōu)化了，要想一個方案全局解決這個問題，在碼猿慢病云管理系統(tǒng)中其實(shí)只要保證這種并發(fā)不高的接口在一定時(shí)間段內(nèi)保證冪等即可，比如5秒之內(nèi)，這樣在5秒之內(nèi)護(hù)士重復(fù)點(diǎn)擊就沒事。
在碼猿慢病云管理系統(tǒng)中新增了一個注解：@RepeatSubmit，代碼如下：
圖片
只需要將該注解標(biāo)注在新增、修改、刪除接口上就能保證在默認(rèn)的5秒之內(nèi)接口冪等。
比如新增住院患者這個接口：
圖片
那么原理是什么？其實(shí)很簡單，先來說下原理，再介紹具體的實(shí)現(xiàn)：
上述6個步驟中其實(shí)只有一點(diǎn)比較難實(shí)現(xiàn)的，其他的都是基本操作，就是獲取這個請求參數(shù)，下面將詳細(xì)介紹一下如何獲取這個請求參數(shù)。
對于form-data的入?yún)⒅恍枰{(diào)用HttpServletRequest的API讀取，但是對于@RequestBody標(biāo)注的入?yún)⑹峭ㄟ^IO流讀取數(shù)據(jù)，且IO流只能被讀取一次，如果在AOP中讀取了，那么在接口層面的入?yún)⒆x取肯定是有問題，報(bào)錯如下：
圖片
解決方案也很簡單，只需要保證IO流能夠多次讀取即可，下面就來介紹一下方案。
這里我們可以利用裝飾者模式對 HttpServletRequest 的功能進(jìn)行增強(qiáng)，具體做法也很簡單，我們重新定義一個 HttpServletRequest：
圖片
圖片
這段代碼并不難，很好懂。
首先在構(gòu)造 RepeatedlyRequestWrapper 的時(shí)候，就通過 IO 流將數(shù)據(jù)讀取出來并存入到一個 byte 數(shù)組中，然后重寫 getReader 和 getInputStream 方法，在這兩個讀取 IO 流的方法中，都從 byte 數(shù)組中返回 IO 流數(shù)據(jù)出來，這樣就實(shí)現(xiàn)了反復(fù)讀取了。
接下來我們定義一個過濾器，讓這個裝飾后的 Request 生效：
圖片
判斷一下，如果請求數(shù)據(jù)類型是 JSON 的話，就把 HttpServletRequest “偷梁換柱”改為 HttpRequestWrapper，然后讓過濾器繼續(xù)往下走。
這樣就可以配置后就可以在程序中反復(fù)讀取參數(shù)了！
解決了參數(shù)讀取的問題，下面就可以輕松實(shí)現(xiàn)這個防重注解了，首先定義注解com.code.ape.codeape.common.security.annotation.RepeatSubmit:
圖片
接下來直接用AOP實(shí)現(xiàn)，com.code.ape.codeape.common.security.component.CodeapeRepeatSubmitAspect代碼如下：
圖片
圖片
邏輯很簡單，上述已經(jīng)介紹過完整的流程，這里需要注意的是參數(shù)的讀取，代碼如下：
圖片
其實(shí)就是將request判斷下是否是經(jīng)過過濾器封裝后的HttpRequestWrapper對象，如果是的話則是@RequestBody入?yún)ⅲ苯訌腎O流中讀取。
本節(jié)內(nèi)容介紹了防重注解@RepeatSubmit的實(shí)現(xiàn)原理，后續(xù)開發(fā)中只需要在非查詢接口中添加這個注解就能保證在一定時(shí)間內(nèi)防止重復(fù)提交。
碼猿慢病云管理系統(tǒng)已經(jīng)在星球中陸續(xù)更新，目前更新內(nèi)容如下：
前言 01 項(xiàng)目架構(gòu)+業(yè)務(wù)介紹 02 三方組件介紹 03 服務(wù)端項(xiàng)目部署 04 前端項(xiàng)目部署 05 多租戶架構(gòu)設(shè)計(jì) 06 醫(yī)療系統(tǒng)中的權(quán)限如何設(shè)計(jì)？ 07 項(xiàng)目搭建 08 關(guān)掉驗(yàn)證碼登錄 09 開發(fā)平臺自動生成業(yè)務(wù)代碼認(rèn)證鑒權(quán) 01 認(rèn)證登錄生成token 02 token檢驗(yàn)、鑒權(quán) 03 token有效期設(shè)置 04 刷新token 05 檢查token 06 服務(wù)中如何獲取當(dāng)前登錄用戶信息？ 07 接口對外暴露 08 接口只允許內(nèi)部調(diào)用怎么處理？ 09 如何實(shí)現(xiàn)token中繼？ 10 當(dāng)前登錄用戶身份信息如何異步傳遞？ 11 科室權(quán)限如何定一個注解自動注入？ 12 一個注解防止接口重復(fù)提交業(yè)務(wù) 01 科室管理 02 醫(yī)院管理 03 角色管理
本文鏈接：http://m.rrqrq.com/showinfo-26-146-0.html一個注解實(shí)現(xiàn)接口冪等，這樣才優(yōu)雅！
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號