1 冪等場景
- 用戶重復(fù)操作：用戶在使用產(chǎn)品時(shí)，可能會(huì)無意的觸發(fā)多筆交易，甚至沒有響應(yīng)而有意觸發(fā)多筆交易
- 網(wǎng)絡(luò)波動(dòng)：因網(wǎng)絡(luò)波動(dòng)，可能會(huì)引起重復(fù)請求
- 分布式消息消費(fèi)：任務(wù)發(fā)布后，使用分布式消息服務(wù)來進(jìn)行消費(fèi)
- 未關(guān)閉的重試機(jī)制：因開發(fā)人員、測試人員或運(yùn)維人員沒有檢查出來，而開啟的重試機(jī)制（如Nginx重試、RPC通信重試或業(yè)務(wù)層重試等）
2 冪等性分析
- 新增類請求
數(shù)據(jù)庫自增主鍵，不具備冪等性 - 查詢類動(dòng)作
重復(fù)查詢不會(huì)產(chǎn)生或變更新的數(shù)據(jù)，因此查詢是天然具備冪等性 - 更新類請求
基于條件查詢的Update，不一定具有冪等性（需要根據(jù)實(shí)際情況進(jìn)行分析判斷） - 刪除類請求
基于主建的Delete具備冪等性
一般業(yè)務(wù)層面都是邏輯刪除（即Update操作），而基于主鍵的邏輯刪除操作也是具有冪等性的
3 冪等重要性
- 電商超賣現(xiàn)象
- 重復(fù)轉(zhuǎn)賬、扣款或付款
- 重復(fù)增加金幣、積分或優(yōu)惠券
超賣現(xiàn)象
比如某商品的庫存為1，此時(shí)用戶1和用戶2并發(fā)購買該商品，用戶1提交訂單后該商品的庫存被修改為0，而此時(shí)用戶2并不知道的情況下提交訂單，該商品的庫存再次被修改為-1這就是超賣現(xiàn)象。
究其深層原因，是因?yàn)閿?shù)據(jù)庫底層的寫操作和讀操作可以同時(shí)進(jìn)行，雖然寫操作默認(rèn)帶有隱式鎖（即對同一數(shù)據(jù)不能同時(shí)進(jìn)行寫操作）但是讀操作默認(rèn)是不帶鎖的，所以當(dāng)用戶1去修改庫存的時(shí)候，用戶2依然可以都到庫存為1，所以出現(xiàn)了超賣現(xiàn)象。
解決方案A：可以對讀操作加上顯式鎖（即在select …語句最后加上for
update）這樣一來用戶1在進(jìn)行讀操作時(shí)用戶2就需要排隊(duì)等待了。但問題來了，如果該商品很熱門并發(fā)量很高那么效率就會(huì)大大的下降，如何解決呢？(解決方案B)
解決方案B：我們可以有條件有選擇的在讀操作上加鎖，比如可以對庫存做一個(gè)判斷，當(dāng)庫存小于一個(gè)量時(shí)開始加鎖，讓購買者排隊(duì)，這樣一來就解決了超賣現(xiàn)象。
4 冪等性設(shè)計(jì)不能脫離業(yè)務(wù)來討論
- 狀態(tài)機(jī)控制
這種方法適合在有狀態(tài)機(jī)流轉(zhuǎn)的情況下，比如就會(huì)訂單的創(chuàng)建和付款，訂單的付款肯定是在之前，這時(shí)我們可以通過在設(shè)計(jì)狀態(tài)字段時(shí)，使用int類型，并且通過值類型的大小來做冪等，比如訂單的創(chuàng)建為0，付款成功為100，付款失敗為99。 - 去重表
這種方法適用于在業(yè)務(wù)中有唯一標(biāo)的插入場景中，比如在以上的支付場景中，如果一個(gè)訂單只會(huì)支付一次，所以訂單ID可以作為唯一標(biāo)識。這時(shí)，我們就可以建一張去重表，并且把唯一標(biāo)識作為唯一索引，在我們實(shí)現(xiàn)時(shí)，把創(chuàng)建支付單據(jù)和寫入去去重表，放在一個(gè)事務(wù)中，如果重復(fù)創(chuàng)建，數(shù)據(jù)庫會(huì)拋出唯一約束異常，操作就會(huì)回滾。 - 插入或更新
這種方法插入并且有唯一索引的情況，比如我們要關(guān)聯(lián)商品品類，其中商品的ID和品類的ID可以構(gòu)成唯一索引，并且在數(shù)據(jù)表中也增加了唯一索引。這時(shí)就可以使用InsertOrUpdate操作。 - 全局唯一ID
如果使用全局唯一ID，就是根據(jù)業(yè)務(wù)的操作和內(nèi)容生成一個(gè)全局ID，在執(zhí)行操作前先根據(jù)這個(gè)全局唯一ID是否存在，來判斷這個(gè)操作是否已經(jīng)執(zhí)行。如果不存在則把全局ID，存儲到存儲系統(tǒng)中，比如數(shù)據(jù)庫、Redis等。如果存在則表示該方法已經(jīng)執(zhí)行。
使用全局唯一ID是一個(gè)通用方案，可以支持插入、更新、刪除業(yè)務(wù)操作。但是這個(gè)方案看起來很美但是實(shí)現(xiàn)起來比較麻煩，下面的方案適用于特定的場景，但是實(shí)現(xiàn)起來比較簡單。
- 多版本控制
這種方法適合在更新的場景中，比如我們要更新商品的名字，這時(shí)我們就可以在更新的接口中增加一個(gè)版本號，來做冪等：
實(shí)戰(zhàn)解決方案
分布式鎖
- 驗(yàn)證顆粒度小、框架層、業(yè)務(wù)層零侵入：filter、攔截器不ok，業(yè)務(wù)層注解AOP
- 過濾重復(fù)請求：AOP環(huán)繞通知，前置通知檢查key存在性、后置通知釋放key，key已存在過濾請求
- 并發(fā)請求：多線程查詢key、創(chuàng)建key不ok，利用redis單線程+保證key操作原子性，引入分布式鎖
- key釋放的原子操作：釋放只能釋放自己線程的key，發(fā)生異常要在finaly中釋放，引入redis事務(wù)，watch監(jiān)聽key
- 極端情況：正常業(yè)務(wù)耗時(shí)，而key過期了；redis主從或者集群，master節(jié)點(diǎn)崩潰，slave節(jié)點(diǎn)未升級，數(shù)據(jù)同步未成功造成數(shù)據(jù)丟失。引入redisson分布式j(luò)ava解決方案，定時(shí)key續(xù)約，集群數(shù)據(jù)分布式內(nèi)存網(wǎng)格存儲
