分布式服務的冪等性設計
目錄
- 為什麽需要保證冪等性
- 唯一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存在說明是重復請求。
分布式服務的冪等性設計