1、概念
任意多次執(zhí)行產生的影響與一次執(zhí)行產生的影響相同父泳，無 副作用般哼。
冪等函數/冪等方法==使用相同參數重復執(zhí)行并可以獲取相同結果的函數
2吴汪、冪等
2.1、API接口
API接口響應情況：成功蒸眠、失敗漾橙、超時
冪等多發(fā)于超時后的上游發(fā)起的重試，下游應保證”同一請求重復執(zhí)行多次對系統(tǒng)造成的影響相同“楞卡。
冪等設計
上游在請求信息中添加全局唯一屬性供下游判重/下游下發(fā)全局唯一屬性值霜运，供上游交互前獲取，供下游做冪>等驗證
下游提供結果/狀態(tài)查詢接口臀晃，異常時上游可通過查詢接口獲取實時結果/狀態(tài)
業(yè)務上：狀態(tài)機限定
實現(xiàn)上
1觉渴、update：樂觀鎖更新機制；悲觀鎖 select for update
2徽惋、insert：數據庫唯一索引兜底---->分庫分表案淋？---->分布式鎖
2.2、HTTP
Get：冪等险绘。http://hl.com/activity/1 獲取資源踢京。資源本身不會因為Get 請求而受到影響、改變宦棺。
Delete：冪等瓣距。http://hl.com/activity/delete/1 刪除id為1的資源。刪除本身造成的影響--資源1被刪除代咸，無論執(zhí)行多少次蹈丸，影響都是相同的--->刪除id為1的資源。
POST：非冪等呐芥。 http://hl.com/activity/create 創(chuàng)建一個資源逻杖。多次請求會創(chuàng)建多個資源，所以是非冪等的思瘟。
冪等設計
token 下發(fā)荸百，防止表單重復提交。
2.3 數據庫
select：冪等滨攻。查到地球??爆炸??也不會導致數據改變够话。
update：
1、update B set name='hl' 非冪等光绕。記錄數量不一樣女嘲，update 影響有所不同。
2诞帐、update B set version=version+1 where id=1 and version=${version} 冪等欣尼。多次執(zhí)行造成影響相同--->將id為的1且version 等于當前version 的記錄，version+1 景埃。
insert：
1媒至、unique index idx_u_name ('name') ; insert into user values (null,'hl'); 冪等。多次執(zhí)行插入谷徙，最終只能插入一條拒啰。
2、no index完慧；insert into user values (null,'hl'); 非冪等谋旦。多次執(zhí)行插入，會重復屈尼。
冪等設計
1册着、樂觀鎖更新機制
2、唯一索引
3脾歧、i tell you
nice to meet all you guys 甲捏。
冪等==多次請求響應報文相同？
多次請求是否返回相同的結果不屬于冪等定義范圍內鞭执。這個可以上下游約定
①下游提供查詢接口司顿，當發(fā)生超時情況下上游調用查詢接口獲取下游處理結果
②下游在內部實現(xiàn)處理前查詢，若查詢到結果直接返回上游
推薦：① 因為超時屬于低概率事件兄纺，大多數非超時場景對DB的查詢對CPU大溜、網絡、IO 等資源是不必要的浪費估脆。
若實際場景對由DB做冪等防重钦奋，異常情況下上游重試會導致DB大量duplicate 報錯，如果對此SQL 異常不能容忍就設計成 select insert 模式冪等疙赠，即：插入前先查詢付材。
