分布式ID生成器

2021-08-09 16:12:29 字數 2593 閱讀 3841

一、需求緣起

幾乎所有的業務系統,都有生成乙個唯一記錄標識的需求,例如:

這個記錄標識往往就是資料庫中的主鍵,資料庫上會建立聚集索引(cluster index),即在物理儲存上以這個字段排序。

這個記錄標識上的查詢,往往又有分頁或者排序的業務需求,例如:

所以往往要有乙個time欄位,並且在time欄位上建立普通索引(non-cluster index)。

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

select message-id/ (order by message-id)/limit 100

強調,能這麼做的前提是,message-id的生成基本是趨勢時間遞增的。

這就引出了記錄標識生成(也就是上文提到的三個***-id)的兩大核心需求:

二、常見方法、不足與優化

方法一:使用資料庫的 auto_increment 

來生成全域性唯一遞增id

優點:缺點:

改進方法:

如上圖所述,由1個寫庫變成3個寫庫,每個寫庫設定不同的auto_increment初始值,以及相同的增長步長

,以保證每個資料庫生成的

id是不同的(上圖中庫0生成

0,3,6,9…,庫1

生成1,4,7,10,庫2

生成2,5,8,11…)

改進後的架構保證了可用性,但缺點是:

為了解決上述兩個問題,引出了第二個常見的方案。

方法二:單點批量id生成服務

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

資料庫寫壓力大,是因為每次生成id都訪問了資料庫,可以使用批量的方式降低資料庫寫壓力。

如上圖所述,資料庫使用雙master保證可用性,資料庫中只儲存當前id的最大值,例如0。

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

當id發完後,再將id的最大值修改為11,就能再次派發6,7,8,9,10,11這些id了,於是資料庫的壓力就降低到原來的1/6。

優點:缺點:

改進方法:

單點服務的常用高可用優化方案是「備用服務」,也叫「影子服務」,所以我們能用以下方法優化上述缺點(1):

如上圖,對外提供的服務是主服務,有乙個影子服務時刻處於備用狀態,當主服務掛了的時候影子服務頂上。

這個切換的過程對呼叫方是透明的,可以自動完成,常用的技術是vip+keepalived,具體就不在這裡展開。

另外,id-gen-service也可以實施水平擴充套件,以解決上述缺點(3),但會引發一致性問題,具體解決方案詳見《**cas在分布式id生成方案上的應用》。

方法三:uuid/guid

有沒有一種本地生成id的方法,即高效能,又時延低呢?

uuid是一種常見的方案:

string id =genuuid();

優點:缺點:

方法四:取當前毫秒數

uuid是乙個本地演算法,生成效能高,但無法保證趨勢遞增,且作為字串id檢索效率低,有沒有一種能保證遞增的本地演算法呢?

取當前毫秒數是一種常見方案:

uint64 id = gentimems();

優點:缺點:

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

方法五:類snowflake演算法

snowflake是twitter開源的分布式id生成演算法,其核心思想為,乙個long型的id:

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

借鑑snowflake的思想,結合各公司的業務邏輯和併發量,可以實現自己的分布式id生成演算法。

舉例,假設某公司id生成器服務的需求如下:

分析過程如下:

這樣設計的64bit標識,可以保證:

缺點:思路比方案重要

分布式 ID 生成器

乙個唯一 id 在乙個分布式系統中是非常重要的乙個業務屬性,其中包括一些如訂單 id,訊息 id 會話 id,他們都有一些共有的特性 全域性唯一很好理解,目的就是唯一標識某個次請求,某個業務。通常有以下幾種方案 可以利用mysql中的自增屬性auto increment來生成全域性唯一 id,也能保...

自學 分布式ID生成器

最近在做乙個專案,遇到了乙個小問題 針對資料庫的主鍵自增這塊怎麼解決,前提是採用分片部署。如果還是用我們之前的方式主鍵自增,會造成乙個表中id的重複。舉例說明 比如有乙個商品表,將這個商品表部署在3臺伺服器上 server1 server2 server3。如果是以前的主鍵自增 server1中會從...

分布式ID生成器(雪花演算法)

目前微服務架構盛行,在分布式系統中的操作中都會有一些全域性性id的需求,所以我們不能使用資料庫本身的自增功能來產生主鍵值,只能由程式來生成唯一的主鍵值。我們採用的是開源的twitter 非官方中文慣稱 推特.是國外的乙個 是乙個社交網路及微部落格服務 的snowflake 雪花 演算法。各個段解析 ...