分佈式服務的冪等性設計

目錄

• 爲何須要保證冪等性
• 惟一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存在說明是重複請求。