目錄
什麼是冪等？
讀和寫請求都需要做冪等嗎？
系統的哪部分需要做冪等？
資料訪問層的增刪改查都需要做冪等處理嗎？
資料庫的修改做冪等（age++的情況展開討論）
分布式系統的id如何生成？
系統中的重複操作，不管執行多少次，都產生一樣的效果，或返回一樣的結果。
讀請求不需要做冪等（因為讀請求不會對資料發生改變）。
寫請求需要做冪等（對資料發生改變了就根據需要做冪等）。
因為資料訪問層和資料庫直接聯絡，涉及到資料的增刪改查，所以需要在資料訪問層做冪等處理。
資料訪問層的增刪改查：
增：主鍵分業務主鍵（唯一）、自增主鍵（最好不用，自增主鍵不好做冪等）。如果是唯一主鍵，那麼就是天然冪等（重複插入會報錯）。
讀：不會改變資料，所以不需要做冪等處理。
改：set age=18或set age++，age++不能保證冪等（主要討論這種情況）。
這種情況，一般都是先查詢，再進行修改，例如：update db set age++ where age=18 （偽**）
或者將相對值改為絕對值的修改：set age=19
修改做冪等通常伴隨著分布式事務的問題：
例如銀行轉賬，a給b轉賬500元，這種就需要做冪等處理。（這裡涉及到分布式事務，以後再寫一篇文章專門介紹分布式事務）
通常的轉賬流程：
1.a發起轉賬500的請求，生成流水號。
2.a賬戶凍結500元，該單號狀態設定為正在轉賬的狀態。
3.b帳號增加500元，該單號狀態設定為轉賬成功狀態。
資料庫的冪等也可以用分布式鎖來進行處理。
這裡推薦乙個twitter用的snowflake來生成分布式系統的id。
什麼是冪等
簡單來說 重複呼叫多次產生的業務結果與呼叫一次產生的業務結果相同 在分布式架構中，我們呼叫乙個遠端服務去完成乙個操作，除了成功和失敗以外，還有未知狀態，那麼針對這個未知狀態，我們會採取一些重試的行為 或者在訊息中介軟體的使用場景中，消費者可能會重複收到訊息。對於這兩種情況，消費端或者服務端需要採取一...
什麼是冪等？如何實現
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 以上問題，就是在單體架構轉成微服務架構之後帶來的問題。當然不是說單體架構下沒有這些問題，在單體架構下同樣要避免重複請求。但是出現的問題要比這少得多。為了解決以上問題，就需要保證介面的冪等性，介面的冪等性實際上就是介面可重複呼叫，在呼叫方多次...
什麼是冪等，什麼情況下需要冪等，如何實現冪等
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次 在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次 當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次 乙個訂單狀態...