常見分布式唯一ID生成策略有哪些區別

本篇內容介紹了“常見分布式唯一ID生成策略有哪些區別”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

簡單分析一下需求

所謂全局唯一的 id 其實往往對應是生成唯一記錄標識的業務需求。

這個 id 常常是數據庫的主鍵，數據庫上會建立聚集索引（cluster index），即在物理存儲上以這個字段排序。這個記錄標識上的查詢，往往又有分頁或者排序的業務需求。所以往往要有一個time字段，并且在time字段上建立普通索引（non-cluster index）。

普通索引存儲的是實際記錄的指針，其訪問效率會比聚集索引慢，如果記錄標識在生成時能夠基本按照時間有序，則可以省去這個time字段的索引查詢。

這就引出了記錄標識生成的兩大核心需求：

• 全局唯一

• 趨勢有序

常見生成策略的優缺點對比

方法一: 用數據庫的 auto_increment 來生成

優點：

• 此方法使用數據庫原有的功能，所以相對簡單

• 能夠保證唯一性

• 能夠保證遞增性

• id 之間的步長是固定且可自定義的
  缺點：

• 可用性難以保證：數據庫常見架構是 一主多從 + 讀寫分離，生成自增ID是寫請求 主庫掛了就玩不轉了

• 擴展性差，性能有上限：因為寫入是單點，數據庫主庫的寫性能決定ID的生成性能上限，并且 難以擴展
  改進方案：

• 冗余主庫，避免寫入單點

• 數據水平切分，保證各主庫生成的ID不重復

如上圖所述，由1個寫庫變成3個寫庫，每個寫庫設置不同的 auto_increment 初始值，以及相同的增長步長，以保證每個數據庫生成的ID是不同的（上圖中DB 01生成0,3,6,9…，DB 02生成1,4,7,10，DB 03生成2,5,8,11…）

改進后的架構保證了可用性，但缺點是

• 喪失了ID生成的“絕對遞增性”：先訪問DB 01生成0,3，再訪問DB 02生成1，可能導致在非常短的時間內，ID生成不是絕對遞增的（這個問題不大，目標是趨勢遞增，不是絕對遞增

• 數據庫的寫壓力依然很大，每次生成ID都要訪問數據庫
  為了解決這些問題，引出了以下方法：

方法二：單點批量ID生成服務

分布式系統之所以難，很重要的原因之一是“沒有一個全局時鐘，難以保證絕對的時序”，要想保證絕對的時序，還是只能使用單點服務，用本地時鐘保證“絕對時序”。

數據庫寫壓力大，是因為每次生成ID都訪問了數據庫，可以使用批量的方式降低數據庫寫壓力。

如上圖所述，數據庫使用雙master保證可用性，數據庫中只存儲當前ID的最大值，例如4。

ID生成服務假設每次批量拉取5個ID，服務訪問數據庫，將當前ID的最大值修改為4，這樣應用訪問ID生成服務索要ID，ID生成服務不需要每次訪問數據庫，就能依次派發0,1,2,3,4這些ID了。

當ID發完后，再將ID的最大值修改為11，就能再次派發6,7,8,9,10,11這些ID了，于是數據庫的壓力就降低到原來的1/6。

優點：

• 保證了ID生成的絕對遞增有序

• 大大的降低了數據庫的壓力，ID生成可以做到每秒生成幾萬幾十萬個
  缺點：

• 服務仍然是單點

• 如果服務掛了，服務重啟起來之后，繼續生成ID可能會不連續，中間出現空洞（服務內存是保存著0,1,2,3,4，數據庫中max-id是4，分配到3時，服務重啟了，下次會從5開始分配，3和4就成了空洞，不過這個問題也不大）
  雖然每秒可以生成幾萬幾十萬個ID，但畢竟還是有性能上限，無法進行水平擴展

改進方案

• 單點服務的常用高可用優化方案是“備用服務”，也叫“影子服務”，所以我們能用以下方法優化上述缺點：

如上圖，對外提供的服務是主服務，有一個影子服務時刻處于備用狀態，當主服務掛了的時候影子服務頂上。這個切換的過程對調用方是透明的，可以自動完成，常用的技術是 vip+keepalived。另外，id generate service 也可以進行水平擴展，以解決上述缺點，但會引發一致性問題。

方法三：uuid / guid

不管是通過數據庫，還是通過服務來生成ID，業務方Application都需要進行一次遠程調用，比較耗時。uuid是一種常見的本地生成ID的方法。

UUID uuid = UUID.randomUUID();

優點：

• 本地生成ID，不需要進行遠程調用，時延低

• 擴展性好，基本可以認為沒有性能上限
  缺點：

• 無法保證趨勢遞增

• uuid過長，往往用字符串表示，作為主鍵建立索引查詢效率低，常見優化方案為“轉化為兩個uint64整數存儲”或者“折半存儲”（折半后不能保證唯一性）

方法四：取當前毫秒數

uuid是一個本地算法，生成性能高，但無法保證趨勢遞增，且作為字符串ID檢索效率低，有沒有一種能保證遞增的本地算法呢？- 取當前毫秒數是一種常見方案。
優點：

• 本地生成ID，不需要進行遠程調用，時延低

• 生成的ID趨勢遞增

• 生成的ID是整數，建立索引后查詢效率高
  缺點：

• 如果并發量超過1000，會生成重復的ID

• 這個缺點要了命了，不能保證ID的唯一性。當然，使用微秒可以降低沖突概率，但每秒最多只能生成1000000個ID，再多的話就一定會沖突了，所以使用微秒并不從根本上解決問題。

方法五：使用 Redis 來生成 id

當使用數據庫來生成ID性能不夠要求的時候，我們可以嘗試使用Redis來生成ID。這主要依賴于Redis是單線程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR 和 INCRBY 來實現。
優點：

• 依賴于數據庫，靈活方便，且性能優于數據庫。

• 數字ID天然排序，對分頁或者需要排序的結果很有幫助。
  缺點：

• 如果系統中沒有Redis，還需要引入新的組件，增加系統復雜度。

• 需要編碼和配置的工作量比較大。

方法六：Twitter 開源的 Snowflake 算法

snowflake 是 twitter 開源的分布式ID生成算法，其核心思想為，一個long型的ID：

• 41 bit 作為毫秒數 - 41位的長度可以使用69年

• 10 bit 作為機器編號 （5個bit是數據中心，5個bit的機器ID） - 10位的長度最多支持部署1024個節點

• 12 bit 作為毫秒內序列號 - 12位的計數順序號支持每個節點每毫秒產生4096個ID序號

算法單機每秒內理論上最多可以生成1000*(2^12)，也就是400W的ID，完全能滿足業務的需求。

“常見分布式唯一ID生成策略有哪些區別”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！