詳解Redis如何保證接口的冪等性
背景
如何防止接口中同樣的數(shù)據(jù)提交,以及如何保證消息不被重復消費,這些都是shigen在學習的過程中遇到的問題。今天,趁著在學習redis的間隙,我寫了一篇文章進行簡單的實現(xiàn)。
注意:僅使用于單機的場景,對于分布式、高并發(fā)場景,還是建議使用分布式鎖。
首先我們分析一下Restful接口和冪等性的關系:
| 請求方式 | 是否冪等 | 對應的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的請求方式做進一步的優(yōu)化。
常用的解決方式
大概主流的解決方案:
token機制(前端帶著在請求頭上帶著標識,后端驗證)
加鎖機制
- 數(shù)據(jù)庫悲觀鎖(鎖表)
- 數(shù)據(jù)庫樂觀鎖(version號進行控制)
- 業(yè)務層分布式鎖(加分布式鎖redisson)
全局唯一索引機制,ID不能重復
redis的set機制
前端按鈕加限制,類似于vue的
v-once指令,但前提是用戶不刷新頁面
今天用到的就是redis的set方法。我們只需要一個注解即可實現(xiàn),接下來看看shigen是如何的設計吧!
代碼實現(xiàn)
- 自定義注解
Idempotent

其中的value表示接口的唯一標識,可以為空,下邊的IdempotentAspect中會講到
- 定義
IdempotentAspect的切片

這里主要是定義一個切片的環(huán)繞通知,在里邊處理主要的接口防刷邏輯
- 冪等性處理類
IdempotentProcessor

接口的唯一標識變成了方法名+方法的參數(shù)
- 冪等性處理接口
IdempotentProcessor的實現(xiàn)類RedisIdempotentProcessor

好的所有的準備已經(jīng)就緒,現(xiàn)在我們寫一個測試的接口測試一下:

采用的是get請求測試,是為了方便。post請求的使用也和案例一樣。
直接寫上一個注解即可。我們還是采用ab進行測試。
ab -n 2 '127.0.0.1:9000/idempotent/test?msg=test'
控制臺的輸出如下:

成功了一次,失敗了1次,并且redis中出現(xiàn)了值為true的keytesttest。java后端也如期的出現(xiàn)了the same requests的異常信息。

到此這篇關于詳解Redis如何保證接口的冪等性的文章就介紹到這了,更多相關Redis保證接口的冪等性內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

