分散式系統中的冪等性-zookeeper與dubbo

現如今我們的系統大多拆分為分散式SOA，或者微服務，一套系統中包含了多個子系統服務，而一個子系統服務往往會去調用另一個服務，而服務調用服務無非就是使用RPC通信或者restful，既然是通信，那麼就有可能再伺服器處理完畢後返回結果的時候掛掉，這個時候用戶端發現很久沒有反應，那麼就會多次點擊按鈕，這樣請求有多次，那麼處理數據的結果是否要統一呢?那是肯定的!尤其再支付場景。

冪等性：就是用戶對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點擊而產生了副作用。舉個最簡單的例子，那就是支付，用戶購買商品使用約支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，用戶再次點擊按鈕，此時會進行第二次扣款，返回結果成功，用戶查詢餘額返發現多扣錢了，流水記錄也變成了兩條...

在以前的單應用系統中，我們只需要把數據操作放入事務中即可，發生錯誤立即回滾，但是再響應客戶端的時候也有可能出現網路中斷或者異常等等。

在增刪改查4個操作中，尤為注意就是增加或者修改，

查詢對於結果是不會有改變的，

刪除只會進行一次，用戶多次點擊產生的結果一樣

修改在大多場景下結果一樣

增加在重複提交的場景下會出現

那麼如何設計介面才能做到冪等呢?

方法一、單次支付請求，也就是直接支付了，不需要額外的資料庫操作了，這個時候發起非同步請求創建一個唯一的ticketId，就是門票，這張門票只能使用一次就作廢，具體步驟如下：

非同步請求獲取門票

調用支付，傳入門票

根據門票ID查詢此次操作是否存在，如果存在則表示該操作已經執行過，直接返回結果;如果不存在，支付扣款，保存結果

返回結果到客戶端

如果步驟4通信失敗，用戶再次發起請求，那麼最終結果還是一樣的

方法二、分散式環境下各個服務相互調用

這邊就要舉例我們的系統了，我們支付的時候先要扣款，然後更新訂單，這個地方就涉及到了訂單服務以及支付服務了。

用戶調用支付，扣款成功後，更新對應訂單狀態，然後再保存流水。

而在這個地方就沒必要使用門票ticketId了，因為會比較閑的麻煩

(支付狀態：未支付，已支付)

步驟：

1、查詢訂單支付狀態

2、如果已經支付，直接返回結果

3、如果未支付，則支付扣款並且保存流水

4、返回支付結果

如果步驟4通信失敗，用戶再次發起請求，那麼最終結果還是一樣的

對於做過支付的朋友，冪等，也可以稱之為沖正，保證客戶端與服務端的交易一致性，避免多次扣款。

然後呢咱們來看一下我們的訂單流程，雖然不是很複雜，但是最後在支付環境是一定要實現冪等性的

另外，在這個訂單過程中，我們也要考慮鎖的問題，既然在分散式環境中，那這個鎖就是分散式鎖，我們可以很好的通過zookeeper來做好分散式鎖，把我們的資源限定給用戶。比方說，在支付的時候，由於多鏈路，假設一開始沒有結賬，最後結賬單位和會計都來做支付，由於考慮並發的可能性，第一個用戶發起的請求可能卡主，第二個用戶發起的請求已經結束，你們第一個請求有可能也會支付成功，那麼這個時候就需要zookeeper來做分散式鎖的控制了

同時，關於多鏈路，並發的時候對於業務肯定需要拆分的，那麼不同的業務作為一個微服務，可以使用dubbo來做服務化，並且註冊到zookeeper，讓調用方來訂閱，這樣可以很好的做好業務分離以及微服務。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！