服務冪等性設計

爲何須要冪等性？

• 想想當轉帳的時候，由於網絡緣由暫時沒收到響應，再次進行轉帳，如何防止重複性的轉帳。這就須要冪等設計。
• 當去自動化安裝軟件的時候，對於已經安裝的軟件，再次發出安裝軟件的命令，是重複安裝軟件，仍是看軟件已經安裝就返回安裝好的結果。

若是從開發角度考慮：

• 請求執行屢次與執行一次的最終結果都是一致的
• 在業務上，同一用戶不能重複下單，商品不超買，不會發生重複轉帳

請求層面冪等

若是要作冪等，首先對請求進行分類，通常分爲讀請求和寫請求，讀請求通常不須要作冪等，讀數據自己不會改變數據，所以無需作冪等，而寫請求可能對數據形成改變，全部部分寫請求須要進行冪等。

從架構層次上，看看那些層會對數據發生改變。

• 網關，業務邏輯通常不會修改數據

• 數據訪問層可能修改數據，咱們只須要對數據訪問層進行冪等性設計

對於數據訪問層CRUD：

• 新增數據的時候，經過主鍵或者某個惟一標識如token，限制某條記錄只能插入一次。

• 更新數據的時候，部分冪等。部分不冪等

  • update user set name='aihe' where id=1; 冪等的
  • update user set age++ where id=1; 非冪等的

• 刪除數據的時候，部分冪等，部分非冪等，在實際刪除的時候不要經過相對值來刪除，通常在刪除以前首先進行一次查詢，而後進行絕對刪除

  • delete from user where id=1; 冪等的
  • delete from user where uid in bottom 10; 非冪等的

真正須要處理的是update操做。如何處理呢？

• 方式一：相對值修改轉換爲絕對值修改。 update user set age=19 where id=1 and age=18; 可是在體量很是大的時候，不是一種好的方式
• 方式二：部分業務有狀態流轉，好比說已轉帳，已收貨。每次操做進行狀態的修改，知足須要的狀態才更新。狀態流轉比較複雜的時候，通常要引入分佈式事務的問題

業務層面冪等

業務層次的冪等如何解決呢？

好比下了一個訂單，可是冗餘部署了多個進程，這個時候存在併發消費的可能性。對此咱們能夠嘗試將並行操做轉換爲串行操做，採用分佈式鎖。

共享資源經過鎖來保證。

常見保證冪等性手段

通常在分佈式系統中，全部請求都會攜帶一個惟一的請求流水號，requestNo，在進行操做以前判斷這個requestNo是否已經入庫了，若是在庫中已經存在，表明已經處理過，若是不存在則繼續處理。

通常一次操做對應的是一個請求流水號，若是請求流水號不一樣，表明的是兩次操做。