1 冪等場景
- 用戶重復(fù)操作：用戶在使用產(chǎn)品時(shí)贩绕，可能會無意的觸發(fā)多筆交易火的，甚至沒有響應(yīng)而有意觸發(fā)多筆交易
- 網(wǎng)絡(luò)波動(dòng)：因網(wǎng)絡(luò)波動(dòng)，可能會引起重復(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ù)查詢不會產(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ā)量很高那么效率就會大大的下降，如何解決呢具钥？(解決方案B)
解決方案B：我們可以有條件有選擇的在讀操作上加鎖豆村，比如可以對庫存做一個(gè)判斷，當(dāng)庫存小于一個(gè)量時(shí)開始加鎖骂删，讓購買者排隊(duì)掌动，這樣一來就解決了超賣現(xiàn)象四啰。
4 冪等性設(shè)計(jì)不能脫離業(yè)務(wù)來討論
- 狀態(tài)機(jī)控制
這種方法適合在有狀態(tài)機(jī)流轉(zhuǎn)的情況下，比如就會訂單的創(chuàng)建和付款粗恢，訂單的付款肯定是在之前柑晒，這時(shí)我們可以通過在設(shè)計(jì)狀態(tài)字段時(shí)，使用int類型眷射，并且通過值類型的大小來做冪等匙赞，比如訂單的創(chuàng)建為0，付款成功為100妖碉，付款失敗為99涌庭。 - 去重表
這種方法適用于在業(yè)務(wù)中有唯一標(biāo)的插入場景中，比如在以上的支付場景中欧宜，如果一個(gè)訂單只會支付一次坐榆，所以訂單ID可以作為唯一標(biāo)識。這時(shí)冗茸，我們就可以建一張去重表席镀，并且把唯一標(biāo)識作為唯一索引，在我們實(shí)現(xiàn)時(shí)蚀狰，把創(chuàng)建支付單據(jù)和寫入去去重表愉昆，放在一個(gè)事務(wù)中职员，如果重復(fù)創(chuàng)建麻蹋，數(shù)據(jù)庫會拋出唯一約束異常，操作就會回滾焊切。 - 插入或更新
這種方法插入并且有唯一索引的情況扮授，比如我們要關(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)格存儲
