常見分布式ID生成政策總結

分布式ID需求

1.全局唯一：不能出現重複ID

2.高可用：ID生成系統是基礎系統，被許多關鍵系統調用，一旦當機，就會造成嚴重影響。

1.Java 的UUID方案

它是在一定的範圍内（從特定的名字空間到全局），唯一的機器生成的辨別符，是以UUID在其他語言中也叫做GUID。

UUID是經由一定的算法機器生成的，為了保證UUID的唯一性，規範定義了包含網卡，MAC位址，時間戳，名字空間（nameSpace）、随機或僞随機數，時序等元素，以及從這些元素生成UUID的算法。UUID隻能由計算機生成。

一個UUID是16位元組長的數字，一共128位。轉換成字元串後，它會變成一個36位元組的字元串。使用的時候可以把中間的-分隔符給去掉，剩下32位元組的字元串。

優點：

UUID的優點是本地生成ID，不需要進行遠端調用，時效好，性能高。

缺點：

16位元組共128位，通常以36位元組長的字元串來表示，在很多應用場景不适應。UUID沒有統一的排序，無法保證趨勢遞增，是以用于資料庫索引字段的效率很低，添加記錄存儲入庫性能差。

對于高并發和大資料量的系統，不建議使用UUID。

2.分布式緩存Redis生成ID：

利用reids的原子操作INCR和INCRBY，生成全局唯一的ID。

3.zookeeper臨時順序節點ID生成器

利用zookeeper的順序節點，生成全局唯一的ID。

4.推特的SnowFlake算法

snowFlag算法是一種著名的分布式伺服器使用者ID生成算法。SnowFlake算法所生成的DI是一個64bit的長整形數字，這64bit被劃分成了4個部分，其中後面三個部分分别别表示時間戳，工作機器ID，序列号。

SnowFlakeID的四個部分，具體介紹如下：

（1）第一個位 占用1bit,其值始終是0，沒有實際作用

（2）時間戳 占用41bit，精确到毫秒，總共可以容納約69年的時間。

（3）工作機器ID 占用10bit，最多可以容納1024個節點

（4）序列号 占用12 bit，最多可以累加到4095.這個值在痛一毫秒同一節點上從0開始不斷累加。

總體來說，在工作節點達到1024頂配的場景下，SnowFlake算法在同一毫秒内最多可以生成ID大緻為：1024 * 4096 =4194304 ，總計400多萬個ID，也就是說，在絕大多數并發場景下是夠用的。

SnowFlake算法的優缺點：

優點：

1.生成ID時不依賴于資料庫，完全在記憶體生成，高性能和高可用。

2.容量大，每秒可以生成幾百萬個ID

3.ID呈現趨勢遞增，後續插入資料庫的所引述時，性能較高。

缺點：

1.依賴于系統時鐘的一緻性，如果某台機器的系統時鐘回撥了，有可能造成ID沖突，或者ID亂序。

2.啟動之前，如果這台機器的系統時間回撥過，那麼有可能出現ID重複的危險。

5.MongoDB的ObjectID

Mongodb是一個分布式的非結構化NoSQL資料庫，每插入一條記錄會自動生成全局唯一的一個“_id”字段值，它是一個12位元組的字元串,可以作為分布式系統中的全局唯一ID。