分佈式服務協調---冪等(Idempotent)機制

背景

      在業務開發中，咱們常會面對防止重複請求的問題。當服務端對於請求的響應涉及數據的修改，或狀態的變動時，可能會形成極大的危害。重複請求的後果在交易系統、售後維權，以及支付系統中尤爲嚴重。
前臺操做的抖動，快速操做，網絡通訊或者後端響應慢，都會增長後端重複處理的機率。 

      重複消息是SOA服務實現中很是常見的問題，你永遠不要期望調用方每次請求消息不同，對於讀操做，重複消息可能無害，可對於寫操做極可能就是災難。

能夠經過冪等(Idempotent)模式處理重複的消息，基本處理思路是：

• 調用者給消息一個惟一請求ID標識。ID標識一個工做單元，這個工做單元只應執行一次，工做單元ID能夠是Schema的一部分，也能夠是一個定製的SOAP Header，服務的Contract 能夠說明這個惟一請求ID標識是必須的；
• 接收者在執行一個工做單元必須先檢驗該工做單元是否已經執行過。檢查是否執行的邏輯一般是根據惟一請求ID ，在服務端查詢請求是否有記錄，是否有對應的響應信息，若是有，直接把響應信息查詢後返回；若是沒有，那麼就當作新請求去處理。

冪等方案

      對時間全局性要求高的，可能就必須選擇DB這種持久化方案比較可靠，可是性能不夠好啊（而後就要考慮loadmemory，以及數據同步的問題，就一步還要考慮實時性要求了）。在空間的要求中，根據不一樣的冪等範圍，能夠考慮分佈式數據庫（分佈式集羣全局流水號冪等）。仍是某種少許數據冪等（可能只須要單臺，作好主備）。

數據的對象和範圍

• 你要考慮你的冪等的全局性：空間全局性和時間全局性。
• 空間全局性：好比是交易流水冪等仍是用戶ID冪等。是某種類型交易流水冪等，仍是某我的|機構|渠道的交易流水冪等
• 時間全局性：是冪等幾秒，仍是幾分鐘，仍是永遠。
• 不一樣的要求，能夠有不同的解決方案、難度和成本。