什么是分布式冪等性

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

冪等性問題

冪等性問題指的是一個接口多次執行的結果應當與一次執行的結果相同(即重復操作不會對數據準確性造成影響)。 在數據不變的情況下，查詢和刪除操作天然具備冪等性，而新增和修改操作默認情況下不能保證冪等。

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

提交一次和提交100次結果是一樣的

1. token機制

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

2. 然后調用業務接口請求時，將token攜帶過去，一般放在請求頭中

3. 服務器判斷token是否存在redis中，存在表示第一次請求，然后刪除token，繼續執行業務。

危險性

2. 利用redis set防重

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

3. 防重表

使用訂單編號orderNo作為防重表的唯一索引，把唯一索引插入去重表，再進行業務操作，且他們在同一個事務下。這個保證了重復請求時，因為去重表唯一約束導致請求失敗，避免了冪等性問題。 注意：去重表和業務表應該在同一個庫中，這樣就能保證了因為同一個事務，即使業務操作失敗了，也會把去重表的數據回滾。這個很好的保證了數據一致性

4. 數據庫樂觀鎖

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

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

根據version版本號，也就是在操作數據庫之前先 獲取到當前商品的version版本號 ， 然后操作的時候帶上此version號。我們梳理下，第一次操作庫存時，得到version為1，調用庫存服務version變為2；但返回給訂單服務出現了問題，訂單服務有一次發起調用庫存服務，當訂單服務傳入的version還是1，再執行上面SQL就不會執行。因為version已經變為2了，where條件不成立。這樣不管調用幾次，只會真正處理一次。

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

5. 業務層分布式鎖

調用接口時，生成唯一id，redis將數據保存到集合中（去重），存在即處理過。可以使用ngxin設置每一個請求的唯一id。

proxy_set_header X-Request-Id $request_id;

6. 生成唯一令牌方案

數據提交前向服務獲取token,設置有效期；提交后服務校驗token，校驗通過刪除舊值生成新值，等待下次獲取。

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

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