分布式服務的冪等性設計
目錄
- 為什麽需要保證冪等性
- 唯一ID
- UUID
- Snowflake
- 共享存儲
- 避免不必要的查詢
為什麽需要保證冪等性
編程中的“冪等性”是指任意多次執行所產生的影響，與一次執行的影響相同。一個擁有冪等性設計的接口，保證無論一次或多次來調用接口，都能夠得到相同的結果。接口的冪等性設計在某些場景下是必需的，例如用戶下單的場景。
我們知道，服務之間的調用存在三種狀態：成功、失敗、超時。超時是一種未知的狀態：被調服務是否執行成功，這個狀態是未知的。上遊服務調用下遊服務超時時可能會進行重試。對於用戶下單的場景的超時重試我們考慮以下問題：
- 是否會導致最終創建了兩條一樣的訂單？
- 是否會扣除兩遍庫存？
- 是否會重復扣除用戶的錢？
如果每一筆訂單都攜帶唯一的序號，下單接口可以借助這個序號，來記錄某次下單操作的狀態。當下單的狀態為成功時，就將重復的執行攔截住，避免出現上述的問題。這種方式是由下遊被調方來保證冪等性。
除此之外，訂單服務也可以提供查詢訂單狀態的接口，上遊在下單之前先進行查詢，確認該筆訂單並沒有成功支付後，再重復進行下單操作。
一般來說，服務本身需要自己保證冪等性，而不應該將冪等性交給上遊的調用方來做。
唯一ID
就上面的冪等性下單接口來說，要做到冪等性，就需要借助一個唯一的ID來標誌每次交易。唯一ID的分配可以有幾種方式：
- 由一個統一的ID分配中心來分配。
- 由上遊服務來生成唯一ID，但必須保證不產生沖突的ID。
采用統一的分配中心來分配唯一ID時，業務方每次調用接口都多了一次調用分配中心獲取唯一ID的請求。這多了額外的開銷。獲取唯一ID有一種方式，是借助mysql的自增索引，這其實也是一個ID分配中心。對服務性能有苛刻要求時，可以采用第二種方式，由主調服務本身來生成這個唯一ID。為了保持不會產生重復的ID，可以使用一下幾種ID生成方法：
UUID
UUID的全稱是Universally Unique Identifier，通用唯一識別碼。具體可以看維基百科的介紹：https://en.wikipedia.org/wiki/Universally_unique_identifier
UUID是一個128bit的數字，用於標誌計算機的信息，雖然UUID不能保證絕對不重復，但重復的概率小到可以被忽略。UUID的生成沒有什麽規律，為了保證UUID的唯一性，規範定義了包括網卡MAC地址、時間戳、名字空間（Namespace）、隨機或偽隨機數、時序等元素，以及從這些元素生成UUID的算法。這也就意味著：
- 128bit，占據了太多的內存空間
- 生成的ID不是人可以看懂的
- 無法保證ID的遞增，某些場景需要按前後排序 無法滿足。
這是一個在線生成UUID的網站：https://www.uuidgenerator.net/ 你可以直觀感受一下UUID。
Snowflake
這是Twitter的一個開源項目，它是一個分布式ID的生成算法，它會產生一個long類型的唯一ID，其核心算法是：
- 時間部分：41bit作為毫秒數，大概可以使用69.7年
- 機器編號部分：10bit作為機器編號，支持1024個機器實例。
- 毫秒內的序列號：12bit，一毫米可以生成4096個序列號
網上有各種語言實現的Snowflake算法的實現，有興趣的閱讀一下實現代碼。
實際上，redis 或是 mongoDB 的全局ID生成器的算法和Snowflake算法大同小異。這是基於redis的分布式ID生成器實現：https://github.com/hengyunabc/redis-id-generator
它的核心思想是：
- 使用41 bit來存放時間，精確到毫秒，可以使用41年。
- 使用12 bit來存放邏輯分片ID，最大分片ID是4095
- 使用10 bit來存放自增長ID，意味著每個節點，每毫秒最多可以生成1024個ID
共享存儲
如果我們的冪等性服務是分布式的，那麽存儲唯一ID也需要采用共享的存儲，這樣每個服務就是無狀態的了。可以使用mysql來存儲，也可以使用k-v存儲例如redis。我在自己的業務中就采用了redis來存儲唯一key。
避免不必要的查詢
並不是所有的請求都是重復的，生產環境下可能99%的請求都不是重復請求。如果每個請求在執行前都要去查詢下唯一ID是否存在，可能會帶來不必要的性能消耗。如果你使用mysql來存儲唯一ID，那麽可以直接進行insert，通過結果來判斷是否插入記錄成功，如果不成功則證明ID已經存在：
insert into ... values ... on DUPLICATE KEY UPDATE ...而如果使用的是redis，也可以使用redis的setEx，設置成功則證明key不存在，否則key存在說明是重復請求。
分布式服務的冪等性設計