什么是分布式冪等性

本篇文章為大家展示了什么是分布式冪等性，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

冪等性問題

冪等性問題指的是一個(gè)接口多次執(zhí)行的結(jié)果應(yīng)當(dāng)與一次執(zhí)行的結(jié)果相同(即重復(fù)操作不會對數(shù)據(jù)準(zhǔn)確性造成影響)。 在數(shù)據(jù)不變的情況下，查詢和刪除操作天然具備冪等性，而新增和修改操作默認(rèn)情況下不能保證冪等。

大白話就是：我點(diǎn)了多少次按鈕，就給我生成一次。

提交一次和提交100次結(jié)果是一樣的

1. token機(jī)制

1. 服務(wù)端提供了發(fā)送token的接口。我們在分析業(yè)務(wù)的時(shí)候，哪些業(yè)務(wù)是存在冪等性問題的。就必須在執(zhí)行業(yè)務(wù)之前，先去獲取token，服務(wù)器會把token保存到redis

2. 然后調(diào)用業(yè)務(wù)接口請求時(shí)，將token攜帶過去，一般放在請求頭中

3. 服務(wù)器判斷token是否存在redis中，存在表示第一次請求，然后刪除token，繼續(xù)執(zhí)行業(yè)務(wù)。

危險(xiǎn)性

2. 利用redis set防重

很多數(shù)據(jù)需要處理，只能被處理一次。比如我們可以計(jì)算數(shù)據(jù)的MD5將其加入redis的set，每次處理數(shù)據(jù)，先看這個(gè)MD5是否已經(jīng)存在，存在就不處理。

3. 防重表

使用訂單編號orderNo作為防重表的唯一索引，把唯一索引插入去重表，再進(jìn)行業(yè)務(wù)操作，且他們在同一個(gè)事務(wù)下。這個(gè)保證了重復(fù)請求時(shí)，因?yàn)槿ブ乇砦ㄒ患s束導(dǎo)致請求失敗，避免了冪等性問題。 注意：去重表和業(yè)務(wù)表應(yīng)該在同一個(gè)庫中，這樣就能保證了因?yàn)橥粋€(gè)事務(wù)，即使業(yè)務(wù)操作失敗了，也會把去重表的數(shù)據(jù)回滾。這個(gè)很好的保證了數(shù)據(jù)一致性

4. 數(shù)據(jù)庫樂觀鎖

這種方式適合在更新場景中。

例如：update t_goods set count = count - 1 , version = version + 1 where g_id = 2 and version

根據(jù)version版本號，也就是在操作數(shù)據(jù)庫之前先 獲取到當(dāng)前商品的version版本號 ， 然后操作的時(shí)候帶上此version號。我們梳理下，第一次操作庫存時(shí)，得到version為1，調(diào)用庫存服務(wù)version變?yōu)?；但返回給訂單服務(wù)出現(xiàn)了問題，訂單服務(wù)有一次發(fā)起調(diào)用庫存服務(wù)，當(dāng)訂單服務(wù)傳入的version還是1，再執(zhí)行上面SQL就不會執(zhí)行。因?yàn)関ersion已經(jīng)變?yōu)?了，where條件不成立。這樣不管調(diào)用幾次，只會真正處理一次。

樂觀鎖主要用于讀多寫少的問題

5. 業(yè)務(wù)層分布式鎖

調(diào)用接口時(shí)，生成唯一id，redis將數(shù)據(jù)保存到集合中（去重），存在即處理過?？梢允褂胣gxin設(shè)置每一個(gè)請求的唯一id。

proxy_set_header X-Request-Id $request_id;

6. 生成唯一令牌方案

數(shù)據(jù)提交前向服務(wù)獲取token,設(shè)置有效期；提交后服務(wù)校驗(yàn)token，校驗(yàn)通過刪除舊值生成新值，等待下次獲取。

如銀聯(lián)提供的付款接口：需要接入商戶提交付款請求時(shí)附帶：source來源，seq序列號。 source+seq在數(shù)據(jù)庫里面做唯一索引，防止多次付款，(并發(fā)時(shí)，只能處理一個(gè)請求)

上述內(nèi)容就是什么是分布式冪等性，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。