背景
如何防止接口中同樣的數(shù)據(jù)提交，以及如何保證消息不被重復(fù)消費(fèi)，這些都是shigen在學(xué)習(xí)的過程中遇到的問題。今天，趁著在學(xué)習(xí)redis的間隙，我寫了一篇文章進(jìn)行簡單的實(shí)現(xiàn)。
注意：僅使用于單機(jī)的場景，對于分布式、高并發(fā)場景，還是建議使用分布式鎖。
首先我們分析一下Restful接口和冪等性的關(guān)系：
| 請求方式 | 是否冪等 | 對應(yīng)的sql案例 |
|---|---|---|
| get | 是 | select * from user; |
| put | 是 | update user set name=‘shigen’ where id =10001; |
| delete | 是 | delete from user where id = 10002; |
| Post | 否 | insert into user (id, name) values(10002, ‘shigen’)； |
可見我們主要是針對post的請求方式做進(jìn)一步的優(yōu)化。
常用的解決方式
大概主流的解決方案：
- token機(jī)制（前端帶著在請求頭上帶著標(biāo)識(shí)，后端驗(yàn)證）
- 加鎖機(jī)制
- 數(shù)據(jù)庫悲觀鎖（鎖表）
- 數(shù)據(jù)庫樂觀鎖（version號(hào)進(jìn)行控制）
- 業(yè)務(wù)層分布式鎖（加分布式鎖redisson）
- 全局唯一索引機(jī)制，ID不能重復(fù)
- redis的set機(jī)制
- 前端按鈕加限制，類似于vue的
v-once指令，但前提是用戶不刷新頁面
今天用到的就是redis的set方法。我們只需要一個(gè)注解即可實(shí)現(xiàn)，接下來看看shigen是如何的設(shè)計(jì)吧！
代碼實(shí)現(xiàn)
- 自定義注解
Idempotent
其中的value表示接口的唯一標(biāo)識(shí)，可以為空，下邊的IdempotentAspect中會(huì)講到
- 定義
IdempotentAspect的切片
這里主要是定義一個(gè)切片的環(huán)繞通知，在里邊處理主要的接口防刷邏輯
- 冪等性處理類
IdempotentProcessor
接口的唯一標(biāo)識(shí)變成了方法名+方法的參數(shù)
- 冪等性處理接口
IdempotentProcessor的實(shí)現(xiàn)類RedisIdempotentProcessor
好的所有的準(zhǔn)備已經(jīng)就緒，現(xiàn)在我們寫一個(gè)測試的接口測試一下：
采用的是get請求測試，是為了方便。post請求的使用也和案例一樣。
直接寫上一個(gè)注解即可。我們還是采用ab進(jìn)行測試。
ab -n 2 '127.0.0.1:9000/idempotent/test?msg=test'
控制臺(tái)的輸出如下：
成功了一次，失敗了1次，并且redis中出現(xiàn)了值為true的keytesttest。java后端也如期的出現(xiàn)了the same requests的異常信息。
好了，以上就是《redis如何保證接口的冪等性》的全部內(nèi)容了，覺得不錯(cuò)的話，記得點(diǎn)贊 在看 轉(zhuǎn)發(fā) 關(guān)注哈，感謝您的支持。文章來源：http://www.zghlxwxcb.cn/news/detail-702134.html
與shigen一起，每天不一樣！文章來源地址http://www.zghlxwxcb.cn/news/detail-702134.html
到了這里，關(guān)于redis如何保證接口的冪等性的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
