大型互聯網公司：經常使用的分佈式ID方案總結！

ID是數據的惟一標識，傳統的作法是利用UUID和數據庫的自增ID，在互聯網企業中，大部分公司使用的都是Mysql，而且由於須要事務支持，因此一般會使用Innodb存儲引擎，UUID太長以及無序，因此並不適合在Innodb中來做爲主鍵，自增ID比較合適，可是隨着公司的業務發展，數據量將愈來愈大，須要對數據進行分表，而分表後，每一個表中的數據都會按本身的節奏進行自增，頗有可能出現ID衝突。這時就須要一個單獨的機制來負責生成惟一ID，生成出來的ID也能夠叫作分佈式ID，或全局ID。下面來分析各個生成分佈式ID的機制。

這篇文章並不會分析的特別詳細，主要是作一些總結，之後再出一些詳細某個方案的文章。

---

數據庫自增ID

第一種方案仍然仍是基於數據庫的自增ID，須要單獨使用一個數據庫實例，在這個實例中新建一個單獨的表：

表結構以下：

CREATE DATABASE `SEQID`;CREATE TABLE SEQID.SEQUENCE_ID (    id bigint(20) unsigned NOT NULL auto_increment,     stub char(10) NOT NULL default '',    PRIMARY KEY (id),    UNIQUE KEY stub (stub)) ENGINE=MyISAM;

可使用下面的語句生成並獲取到一個自增ID

begin;replace into SEQUENCE_ID (stub) VALUES ('anyword');select last_insert_id();commit;

stub字段在這裏並無什麼特殊的意義，只是爲了方便的去插入數據，只有能插入數據才能產生自增id。而對於插入咱們用的是replace，replace會先看是否存在stub指定值同樣的數據，若是存在則先delete再insert，若是不存在則直接insert。

這種生成分佈式ID的機制，須要一個單獨的Mysql實例，雖然可行，可是基於性能與可靠性來考慮的話都不夠，業務系統每次須要一個ID時，都須要請求數據庫獲取，性能低，而且若是此數據庫實例下線了，那麼將影響全部的業務系統。

爲了解決數據庫可靠性問題，咱們可使用第二種分佈式ID生成方案。

數據庫多主模式

若是咱們兩個數據庫組成一個主從模式集羣，正常狀況下能夠解決數據庫可靠性問題，可是若是主庫掛掉後，數據沒有及時同步到從庫，這個時候會出現ID重複的現象。咱們可使用雙主模式集羣，也就是兩個Mysql實例都能單獨的生產自增ID，這樣可以提升效率，可是若是不通過其餘改造的話，這兩個Mysql實例極可能會生成一樣的ID。須要單獨給每一個Mysql實例配置不一樣的起始值和自增步長。

第一臺Mysql實例配置：

set @@auto_increment_offset = 1;     -- 起始值set @@auto_increment_increment = 2;  -- 步長

第二臺Mysql實例配置：

set @@auto_increment_offset = 2;     -- 起始值set @@auto_increment_increment = 2;  -- 步長

通過上面的配置後，這兩個Mysql實例生成的id序列以下： mysql1,起始值爲1,步長爲2,ID生成的序列爲：1,3,5,7,9,... mysql2,起始值爲2,步長爲2,ID生成的序列爲：2,4,6,8,10,...

對於這種生成分佈式ID的方案，須要單獨新增一個生成分佈式ID應用，好比DistributIdService，該應用提供一個接口供業務應用獲取ID，業務應用須要一個ID時，經過rpc的方式請求DistributIdService，DistributIdService隨機去上面的兩個Mysql實例中去獲取ID。

實行這種方案後，就算其中某一臺Mysql實例下線了，也不會影響DistributIdService，DistributIdService仍然能夠利用另一臺Mysql來生成ID。

可是這種方案的擴展性不太好，若是兩臺Mysql實例不夠用，須要新增Mysql實例來提升性能時，這時就會比較麻煩。

如今若是要新增一個實例mysql3，要怎麼操做呢？ 第一，mysql一、mysql2的步長確定都要修改成3，並且只能是人工去修改，這是須要時間的。 第二，由於mysql1和mysql2是不停在自增的，對於mysql3的起始值咱們可能要定得大一點，以給充分的時間去修改mysql1，mysql2的步長。 第三，在修改步長的時候極可能會出現重複ID，要解決這個問題，可能須要停機才行。

爲了解決上面的問題，以及可以進一步提升DistributIdService的性能，若是使用第三種生成分佈式ID機制。

號段模式

咱們可使用號段的方式來獲取自增ID，號段能夠理解成批量獲取，好比DistributIdService從數據庫獲取ID時，若是能批量獲取多個ID並緩存在本地的話，那樣將大大提供業務應用獲取ID的效率。

好比DistributIdService每次從數據庫獲取ID時，就獲取一個號段，好比(1,1000]，這個範圍表示了1000個ID，業務應用在請求DistributIdService提供ID時，DistributIdService只須要在本地從1開始自增並返回便可，而不須要每次都請求數據庫，一直到本地自增到1000時，也就是當前號段已經被用完時，纔去數據庫從新獲取下一號段。

因此，咱們須要對數據庫表進行改動，以下：

CREATE TABLE id_generator (  id int(10) NOT NULL,  current_max_id bigint(20) NOT NULL COMMENT '當前最大id',  increment_step int(10) NOT NULL COMMENT '號段的長度',  PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

這個數據庫表用來記錄自增步長以及當前自增ID的最大值（也就是當前已經被申請的號段的最後一個值），由於自增邏輯被移到DistributIdService中去了，因此數據庫不須要這部分邏輯了。

這種方案再也不強依賴數據庫，就算數據庫不可用，那麼DistributIdService也能繼續支撐一段時間。可是若是DistributIdService重啓，會丟失一段ID，致使ID空洞。

爲了提升DistributIdService的高可用，須要作一個集羣，業務在請求DistributIdService集羣獲取ID時，會隨機的選擇某一個DistributIdService節點進行獲取，對每個DistributIdService節點來講，數據庫鏈接的是同一個數據庫，那麼可能會產生多個DistributIdService節點同時請求數據庫獲取號段，那麼這個時候須要利用樂觀鎖來進行控制，好比在數據庫表中增長一個version字段，在獲取號段時使用以下SQL：

update id_generator set current_max_id=#{newMaxId}, version=version+1 where version = #{version}

由於newMaxId是DistributIdService中根據oldMaxId+步長算出來的，只要上面的update更新成功了就表示號段獲取成功了。

爲了提供數據庫層的高可用，須要對數據庫使用多主模式進行部署，對於每一個數據庫來講要保證生成的號段不重複，這就須要利用最開始的思路，再在剛剛的數據庫表中增長起始值和步長，好比若是如今是兩臺Mysql，那麼 mysql1將生成號段（1,1001]，自增的時候序列爲1，3，4，5，7.... mysql1將生成號段（2,1002]，自增的時候序列爲2，4，6，8，10...

更詳細的能夠參考滴滴開源的TinyId：https://github.com/didi/tinyi...

在TinyId中還增長了一步來提升效率，在上面的實現中，ID自增的邏輯是在DistributIdService中實現的，而實際上能夠把自增的邏輯轉移到業務應用本地，這樣對於業務應用來講只須要獲取號段，每次自增時再也不須要請求調用DistributIdService了。

雪花算法

上面的三種方法總的來講是基於自增思想的，而接下來就介紹比較著名的雪花算法-snowflake。

咱們能夠換個角度來對分佈式ID進行思考，只要能讓負責生成分佈式ID的每臺機器在每毫秒內生成不同的ID就好了。

snowflake是twitter開源的分佈式ID生成算法，是一種算法，因此它和上面的三種生成分佈式ID機制不太同樣，它不依賴數據庫。

核心思想是：分佈式ID固定是一個long型的數字，一個long型佔8個字節，也就是64個bit，原始snowflake算法中對於bit的分配以下圖：

• 第一個bit位是標識部分，在java中因爲long的最高位是符號位，正數是0，負數是1，通常生成的ID爲正數，因此固定爲0。
• 時間戳部分佔41bit，這個是毫秒級的時間，通常實現上不會存儲當前的時間戳，而是時間戳的差值（當前時間-固定的開始時間），這樣可使產生的ID從更小值開始；41位的時間戳可使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
• 工做機器id佔10bit，這裏比較靈活，好比，可使用前5位做爲數據中心機房標識，後5位做爲單機房機器標識，能夠部署1024個節點。
• 序列號部分佔12bit，支持同一毫秒內同一個節點能夠生成4096個ID

根據這個算法的邏輯，只須要將這個算法用Java語言實現出來，封裝爲一個工具方法，那麼各個業務應用能夠直接使用該工具方法來獲取分佈式ID，只需保證每一個業務應用有本身的工做機器id便可，而不須要單獨去搭建一個獲取分佈式ID的應用。

snowflake算法實現起來並不難，提供一個github上用java實現的：https://github.com/beyondfeng...

在大廠裏，其實並無直接使用snowflake，而是進行了改造，由於snowflake算法中最難實踐的就是工做機器id，原始的snowflake算法須要人工去爲每臺機器去指定一個機器id，並配置在某個地方從而讓snowflake今後處獲取機器id。

可是在大廠裏，機器是不少的，人力成本太大且容易出錯，因此大廠對snowflake進行了改造。

百度（uid-generator）

github地址：uid-generator

uid-generator使用的就是snowflake，只是在生產機器id，也叫作workId時有所不一樣。

uid-generator中的workId是由uid-generator自動生成的，而且考慮到了應用部署在docker上的狀況，在uid-generator中用戶能夠本身去定義workId的生成策略，默認提供的策略是：應用啓動時由數據庫分配。說的簡單一點就是：應用在啓動時會往數據庫表(uid-generator須要新增一個WORKER_NODE表)中去插入一條數據，數據插入成功後返回的該數據對應的自增惟一id就是該機器的workId，而數據由host，port組成。

對於uid-generator中的workId，佔用了22個bit位，時間佔用了28個bit位，序列化佔用了13個bit位，須要注意的是，和原始的snowflake不太同樣，時間的單位是秒，而不是毫秒，workId也不同，同一個應用每重啓一次就會消費一個workId。

具體可參考https://github.com/baidu/uid-..._cn.md

美團（Leaf）

github地址：Leaf

美團的Leaf也是一個分佈式ID生成框架。它很是全面，即支持號段模式，也支持snowflake模式。號段模式這裏就不介紹了，和上面的分析相似。

Leaf中的snowflake模式和原始snowflake算法的不一樣點，也主要在workId的生成，Leaf中workId是基於ZooKeeper的順序Id來生成的，每一個應用在使用Leaf-snowflake時，在啓動時都會都在Zookeeper中生成一個順序Id，至關於一臺機器對應一個順序節點，也就是一個workId。

總結

總得來講，上面兩種都是自動生成workId，以讓系統更加穩定以及減小人工成功。

Redis

這裏額外再介紹一下使用Redis來生成分佈式ID，其實和利用Mysql自增ID相似，能夠利用Redis中的incr命令來實現原子性的自增與返回，好比：

127.0.0.1:6379> set seq_id 1     // 初始化自增ID爲1OK127.0.0.1:6379> incr seq_id      // 增長1，並返回(integer) 2127.0.0.1:6379> incr seq_id      // 增長1，並返回(integer) 3

使用redis的效率是很是高的，可是要考慮持久化的問題。Redis支持RDB和AOF兩種持久化的方式。

RDB持久化至關於定時打一個快照進行持久化，若是打完快照後，連續自增了幾回，還沒來得及作下一次快照持久化，這個時候Redis掛掉了，重啓Redis後會出現ID重複。

AOF持久化至關於對每條寫命令進行持久化，若是Redis掛掉了，不會出現ID重複的現象，可是會因爲incr命令過得，致使重啓恢復數據時間過長。

---

推薦閱讀

金三銀四季，阿里工做10多年Java大牛的「心得」，獻給迷茫中的你