背景
下面是阿里巴巴開發規約的防重規範，可見系統冪等沒設計好，後果很嚴重。在很多高併發系統中，產生重複數據概率非常大，系統必須做好冪等。
學習目標
- 學會設計冪等
- 知道什麼情況下需要冪等
代碼例子
冪等主要手段就是通過表中的唯一約束實現
程序員們開始學起來-冪等。
系統背景
分佈式系統如，A【前端輸入驗證等】-------->B【計算然後入庫表數據】
注意我分析的不是傳統單機部署的系統。
冪等設計1
表中的【請求ID】字段如何設計，一般沒有明確冪等條件的話，直接設計成UUID
String uuid = UUID.randomUUID().toString().replace("-", "").toLowerCase();
UUID最少在3000+年內不會重複。
冪等設計2
有明確冪等條件了，如產品ID不能重複，就可以把【請求ID字段】賦值產品ID
type字段當然是產品操作標識，如產品新增。
具體新增邏輯：
- 先select冪等表數據是否存在，
- 然後insert冪等表【高併發下重複數據這裡就DB唯一約束異常了】，
- 然後是具體業務表操作。
冪等就這樣完美的實現了。
需要冪等場景
- 核心業務數據新增，如電影系統中內容新增；審批流系統多人審批同一數據時，可能導致審批多次。
- 定時任務觸發數據生成時，定時任務有時可能重複觸發，導致數據生成多次。
在來個案例：定時任務一般是【業務ID+時間維度】當約束條件，如：用戶ID+YYYYMMDD，用戶每小時執行某業務邏輯。這樣相同時間段內不可能有相同數據任務入庫了。
什麼情況會發多次相同數據
- 【系統重試導致】分佈式系統下，上游系統有失敗重發機制，可能導致數據重複發送
- 【人為導致】多人操作同條數據時，可能導致重複數據。
總結
- 關鍵業務數據新增操作時一定要做好冪等，別等到上線了才發現，數據庫多了條髒數據。
- 合格的java軟件開發工程師必須懂冪等，冪等做好跟髒數據說拜拜。
可能被吐槽
- 你select+insert操作即可，一樣可以冪等啊【高併發下，這樣真防不住】
- 鎖和冪等是兩個概念，我沒一起講，我有專門講鎖的文章，鎖是解決數據一致性問題的。
又get到冪等知識的，請關注啊
分享到:
閱讀更多 程序汪汪 的文章
