互聯(lián)網(wǎng)的分布式ID的示例分析

本篇文章為大家展示了互聯(lián)網(wǎng)的分布式ID的示例分析，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

ID是數(shù)據(jù)的唯一標(biāo)識(shí)，傳統(tǒng)的做法是利用UUID和數(shù)據(jù)庫(kù)的自增ID，在互聯(lián)網(wǎng)企業(yè)中，大部分公司使用的都是Mysql，并且因?yàn)樾枰聞?wù)支持，所以通常會(huì)使用Innodb存儲(chǔ)引擎，UUID太長(zhǎng)以及無(wú)序，所以并不適合在Innodb中來(lái)作為主鍵，自增ID比較合適，但是隨著公司的業(yè)務(wù)發(fā)展，數(shù)據(jù)量將越來(lái)越大，需要對(duì)數(shù)據(jù)進(jìn)行分表，而分表后，每個(gè)表中的數(shù)據(jù)都會(huì)按自己的節(jié)奏進(jìn)行自增，很有可能出現(xiàn)ID沖突。這時(shí)就需要一個(gè)單獨(dú)的機(jī)制來(lái)負(fù)責(zé)生成唯一ID，生成出來(lái)的ID也可以叫做分布式ID，或全局ID。下面來(lái)分析各個(gè)生成分布式ID的機(jī)制。 這篇文章并不會(huì)分析的特別詳細(xì)，主要是做一些總結(jié)，以后再出一些詳細(xì)某個(gè)方案的文章。

數(shù)據(jù)庫(kù)自增ID

第一種方案仍然還是基于數(shù)據(jù)庫(kù)的自增ID，需要單獨(dú)使用一個(gè)數(shù)據(jù)庫(kù)實(shí)例，在這個(gè)實(shí)例中新建一個(gè)單獨(dú)的表：

表結(jié)構(gòu)如下：

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;

可以使用下面的語(yǔ)句生成并獲取到一個(gè)自增ID

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

stub字段在這里并沒(méi)有什么特殊的意義，只是為了方便的去插入數(shù)據(jù)，只有能插入數(shù)據(jù)才能產(chǎn)生自增id。而對(duì)于插入我們用的是replace，replace會(huì)先看是否存在stub指定值一樣的數(shù)據(jù)，如果存在則先delete再insert，如果不存在則直接insert。

這種生成分布式ID的機(jī)制，需要一個(gè)單獨(dú)的Mysql實(shí)例，雖然可行，但是基于性能與可靠性來(lái)考慮的話都不夠，業(yè)務(wù)系統(tǒng)每次需要一個(gè)ID時(shí)，都需要請(qǐng)求數(shù)據(jù)庫(kù)獲取，性能低，并且如果此數(shù)據(jù)庫(kù)實(shí)例下線了，那么將影響所有的業(yè)務(wù)系統(tǒng)。

為了解決數(shù)據(jù)庫(kù)可靠性問(wèn)題，我們可以使用第二種分布式ID生成方案。

數(shù)據(jù)庫(kù)多主模式

如果我們兩個(gè)數(shù)據(jù)庫(kù)組成一個(gè)主從模式集群，正常情況下可以解決數(shù)據(jù)庫(kù)可靠性問(wèn)題，但是如果主庫(kù)掛掉后，數(shù)據(jù)沒(méi)有及時(shí)同步到從庫(kù)，這個(gè)時(shí)候會(huì)出現(xiàn)ID重復(fù)的現(xiàn)象。我們可以使用雙主模式集群，也就是兩個(gè)Mysql實(shí)例都能單獨(dú)的生產(chǎn)自增ID，這樣能夠提高效率，但是如果不經(jīng)過(guò)其他改造的話，這兩個(gè)Mysql實(shí)例很可能會(huì)生成同樣的ID。需要單獨(dú)給每個(gè)Mysql實(shí)例配置不同的起始值和自增步長(zhǎng)。

第一臺(tái)Mysql實(shí)例配置：

set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長(zhǎng)

第二臺(tái)Mysql實(shí)例配置：

set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長(zhǎng)

經(jīng)過(guò)上面的配置后，這兩個(gè)Mysql實(shí)例生成的id序列如下： mysql1,起始值為1,步長(zhǎng)為2,ID生成的序列為：1,3,5,7,9,... mysql2,起始值為2,步長(zhǎng)為2,ID生成的序列為：2,4,6,8,10,...

對(duì)于這種生成分布式ID的方案，需要單獨(dú)新增一個(gè)生成分布式ID應(yīng)用，比如DistributIdService，該應(yīng)用提供一個(gè)接口供業(yè)務(wù)應(yīng)用獲取ID，業(yè)務(wù)應(yīng)用需要一個(gè)ID時(shí)，通過(guò)rpc的方式請(qǐng)求DistributIdService，DistributIdService隨機(jī)去上面的兩個(gè)Mysql實(shí)例中去獲取ID。

實(shí)行這種方案后，就算其中某一臺(tái)Mysql實(shí)例下線了，也不會(huì)影響DistributIdService，DistributIdService仍然可以利用另外一臺(tái)Mysql來(lái)生成ID。

但是這種方案的擴(kuò)展性不太好，如果兩臺(tái)Mysql實(shí)例不夠用，需要新增Mysql實(shí)例來(lái)提高性能時(shí)，這時(shí)就會(huì)比較麻煩。

現(xiàn)在如果要新增一個(gè)實(shí)例mysql3，要怎么操作呢？ 第一，mysql1、mysql2的步長(zhǎng)肯定都要修改為3，而且只能是人工去修改，這是需要時(shí)間的。 第二，因?yàn)閙ysql1和mysql2是不停在自增的，對(duì)于mysql3的起始值我們可能要定得大一點(diǎn)，以給充分的時(shí)間去修改mysql1，mysql2的步長(zhǎng)。 第三，在修改步長(zhǎng)的時(shí)候很可能會(huì)出現(xiàn)重復(fù)ID，要解決這個(gè)問(wèn)題，可能需要停機(jī)才行。

為了解決上面的問(wèn)題，以及能夠進(jìn)一步提高DistributIdService的性能，如果使用第三種生成分布式ID機(jī)制。

號(hào)段模式

我們可以使用號(hào)段的方式來(lái)獲取自增ID，號(hào)段可以理解成批量獲取，比如DistributIdService從數(shù)據(jù)庫(kù)獲取ID時(shí)，如果能批量獲取多個(gè)ID并緩存在本地的話，那樣將大大提供業(yè)務(wù)應(yīng)用獲取ID的效率。

比如DistributIdService每次從數(shù)據(jù)庫(kù)獲取ID時(shí)，就獲取一個(gè)號(hào)段，比如(1,1000]，這個(gè)范圍表示了1000個(gè)ID，業(yè)務(wù)應(yīng)用在請(qǐng)求DistributIdService提供ID時(shí)，DistributIdService只需要在本地從1開(kāi)始自增并返回即可，而不需要每次都請(qǐng)求數(shù)據(jù)庫(kù)，一直到本地自增到1000時(shí)，也就是當(dāng)前號(hào)段已經(jīng)被用完時(shí)，才去數(shù)據(jù)庫(kù)重新獲取下一號(hào)段。

所以，我們需要對(duì)數(shù)據(jù)庫(kù)表進(jìn)行改動(dòng)，如下：

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

這個(gè)數(shù)據(jù)庫(kù)表用來(lái)記錄自增步長(zhǎng)以及當(dāng)前自增ID的最大值（也就是當(dāng)前已經(jīng)被申請(qǐng)的號(hào)段的最后一個(gè)值），因?yàn)樽栽鲞壿嫳灰频紻istributIdService中去了，所以數(shù)據(jù)庫(kù)不需要這部分邏輯了。

這種方案不再?gòu)?qiáng)依賴(lài)數(shù)據(jù)庫(kù)，就算數(shù)據(jù)庫(kù)不可用，那么DistributIdService也能繼續(xù)支撐一段時(shí)間。但是如果DistributIdService重啟，會(huì)丟失一段ID，導(dǎo)致ID空洞。

為了提高DistributIdService的高可用，需要做一個(gè)集群，業(yè)務(wù)在請(qǐng)求DistributIdService集群獲取ID時(shí)，會(huì)隨機(jī)的選擇某一個(gè)DistributIdService節(jié)點(diǎn)進(jìn)行獲取，對(duì)每一個(gè)DistributIdService節(jié)點(diǎn)來(lái)說(shuō)，數(shù)據(jù)庫(kù)連接的是同一個(gè)數(shù)據(jù)庫(kù)，那么可能會(huì)產(chǎn)生多個(gè)DistributIdService節(jié)點(diǎn)同時(shí)請(qǐng)求數(shù)據(jù)庫(kù)獲取號(hào)段，那么這個(gè)時(shí)候需要利用樂(lè)觀鎖來(lái)進(jìn)行控制，比如在數(shù)據(jù)庫(kù)表中增加一個(gè)version字段，在獲取號(hào)段時(shí)使用如下SQL：

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

因?yàn)閚ewMaxId是DistributIdService中根據(jù)oldMaxId+步長(zhǎng)算出來(lái)的，只要上面的update更新成功了就表示號(hào)段獲取成功了。

為了提供數(shù)據(jù)庫(kù)層的高可用，需要對(duì)數(shù)據(jù)庫(kù)使用多主模式進(jìn)行部署，對(duì)于每個(gè)數(shù)據(jù)庫(kù)來(lái)說(shuō)要保證生成的號(hào)段不重復(fù)，這就需要利用最開(kāi)始的思路，再在剛剛的數(shù)據(jù)庫(kù)表中增加起始值和步長(zhǎng)，比如如果現(xiàn)在是兩臺(tái)Mysql，那么 mysql1將生成號(hào)段（1,1001]，自增的時(shí)候序列為1，3，4，5，7.... mysql1將生成號(hào)段（2,1002]，自增的時(shí)候序列為2，4，6，8，10...

更詳細(xì)的可以參考滴滴開(kāi)源的TinyId：https://github.com/didi/tinyid/wiki/tinyid%E5%8E%9F%E7%90%86%E4%BB%8B%E7%BB%8D

在TinyId中還增加了一步來(lái)提高效率，在上面的實(shí)現(xiàn)中，ID自增的邏輯是在DistributIdService中實(shí)現(xiàn)的，而實(shí)際上可以把自增的邏輯轉(zhuǎn)移到業(yè)務(wù)應(yīng)用本地，這樣對(duì)于業(yè)務(wù)應(yīng)用來(lái)說(shuō)只需要獲取號(hào)段，每次自增時(shí)不再需要請(qǐng)求調(diào)用DistributIdService了。

雪花算法

上面的三種方法總的來(lái)說(shuō)是基于自增思想的，而接下來(lái)就介紹比較著名的雪花算法-snowflake。

我們可以換個(gè)角度來(lái)對(duì)分布式ID進(jìn)行思考，只要能讓負(fù)責(zé)生成分布式ID的每臺(tái)機(jī)器在每毫秒內(nèi)生成不一樣的ID就行了。

snowflake是twitter開(kāi)源的分布式ID生成算法，是一種算法，所以它和上面的三種生成分布式ID機(jī)制不太一樣，它不依賴(lài)數(shù)據(jù)庫(kù)。

核心思想是：分布式ID固定是一個(gè)long型的數(shù)字，一個(gè)long型占8個(gè)字節(jié)，也就是64個(gè)bit，原始snowflake算法中對(duì)于bit的分配如下圖：

• 第一個(gè)bit位是標(biāo)識(shí)部分，在java中由于long的最高位是符號(hào)位，正數(shù)是0，負(fù)數(shù)是1，一般生成的ID為正數(shù)，所以固定為0。

• 時(shí)間戳部分占41bit，這個(gè)是毫秒級(jí)的時(shí)間，一般實(shí)現(xiàn)上不會(huì)存儲(chǔ)當(dāng)前的時(shí)間戳，而是時(shí)間戳的差值（當(dāng)前時(shí)間-固定的開(kāi)始時(shí)間），這樣可以使產(chǎn)生的ID從更小值開(kāi)始；41位的時(shí)間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年

• 工作機(jī)器id占10bit，這里比較靈活，比如，可以使用前5位作為數(shù)據(jù)中心機(jī)房標(biāo)識(shí)，后5位作為單機(jī)房機(jī)器標(biāo)識(shí)，可以部署1024個(gè)節(jié)點(diǎn)。

• 序列號(hào)部分占12bit，支持同一毫秒內(nèi)同一個(gè)節(jié)點(diǎn)可以生成4096個(gè)ID

根據(jù)這個(gè)算法的邏輯，只需要將這個(gè)算法用Java語(yǔ)言實(shí)現(xiàn)出來(lái)，封裝為一個(gè)工具方法，那么各個(gè)業(yè)務(wù)應(yīng)用可以直接使用該工具方法來(lái)獲取分布式ID，只需保證每個(gè)業(yè)務(wù)應(yīng)用有自己的工作機(jī)器id即可，而不需要單獨(dú)去搭建一個(gè)獲取分布式ID的應(yīng)用。

snowflake算法實(shí)現(xiàn)起來(lái)并不難，提供一個(gè)github上用java實(shí)現(xiàn)的：https://github.com/beyondfengyu/SnowFlake

在大廠里，其實(shí)并沒(méi)有直接使用snowflake，而是進(jìn)行了改造，因?yàn)閟nowflake算法中最難實(shí)踐的就是工作機(jī)器id，原始的snowflake算法需要人工去為每臺(tái)機(jī)器去指定一個(gè)機(jī)器id，并配置在某個(gè)地方從而讓snowflake從此處獲取機(jī)器id。

但是在大廠里，機(jī)器是很多的，人力成本太大且容易出錯(cuò)，所以大廠對(duì)snowflake進(jìn)行了改造。

百度（uid-generator）

github地址：uid-generator

uid-generator使用的就是snowflake，只是在生產(chǎn)機(jī)器id，也叫做workId時(shí)有所不同。

uid-generator中的workId是由uid-generator自動(dòng)生成的，并且考慮到了應(yīng)用部署在docker上的情況，在uid-generator中用戶(hù)可以自己去定義workId的生成策略，默認(rèn)提供的策略是：應(yīng)用啟動(dòng)時(shí)由數(shù)據(jù)庫(kù)分配。說(shuō)的簡(jiǎn)單一點(diǎn)就是：應(yīng)用在啟動(dòng)時(shí)會(huì)往數(shù)據(jù)庫(kù)表(uid-generator需要新增一個(gè)WORKER_NODE表)中去插入一條數(shù)據(jù)，數(shù)據(jù)插入成功后返回的該數(shù)據(jù)對(duì)應(yīng)的自增唯一id就是該機(jī)器的workId，而數(shù)據(jù)由host，port組成。

對(duì)于uid-generator中的workId，占用了22個(gè)bit位，時(shí)間占用了28個(gè)bit位，序列化占用了13個(gè)bit位，需要注意的是，和原始的snowflake不太一樣，時(shí)間的單位是秒，而不是毫秒，workId也不一樣，同一個(gè)應(yīng)用每重啟一次就會(huì)消費(fèi)一個(gè)workId。

具體可參考https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md

美團(tuán)（Leaf）

github地址：Leaf

美團(tuán)的Leaf也是一個(gè)分布式ID生成框架。它非常全面，即支持號(hào)段模式，也支持snowflake模式。號(hào)段模式這里就不介紹了，和上面的分析類(lèi)似。

Leaf中的snowflake模式和原始snowflake算法的不同點(diǎn)，也主要在workId的生成，Leaf中workId是基于ZooKeeper的順序Id來(lái)生成的，每個(gè)應(yīng)用在使用Leaf-snowflake時(shí)，在啟動(dòng)時(shí)都會(huì)都在Zookeeper中生成一個(gè)順序Id，相當(dāng)于一臺(tái)機(jī)器對(duì)應(yīng)一個(gè)順序節(jié)點(diǎn)，也就是一個(gè)workId。

總結(jié)

總得來(lái)說(shuō)，上面兩種都是自動(dòng)生成workId，以讓系統(tǒng)更加穩(wěn)定以及減少人工成功。

Redis

這里額外再介紹一下使用Redis來(lái)生成分布式ID，其實(shí)和利用Mysql自增ID類(lèi)似，可以利用Redis中的incr命令來(lái)實(shí)現(xiàn)原子性的自增與返回，比如：

127.0.0.1:6379> set seq_id 1     // 初始化自增ID為1
OK
127.0.0.1:6379> incr seq_id      // 增加1，并返回
(integer) 2
127.0.0.1:6379> incr seq_id      // 增加1，并返回
(integer) 3

使用redis的效率是非常高的，但是要考慮持久化的問(wèn)題。Redis支持RDB和AOF兩種持久化的方式。

RDB持久化相當(dāng)于定時(shí)打一個(gè)快照進(jìn)行持久化，如果打完快照后，連續(xù)自增了幾次，還沒(méi)來(lái)得及做下一次快照持久化，這個(gè)時(shí)候Redis掛掉了，重啟Redis后會(huì)出現(xiàn)ID重復(fù)。

AOF持久化相當(dāng)于對(duì)每條寫(xiě)命令進(jìn)行持久化，如果Redis掛掉了，不會(huì)出現(xiàn)ID重復(fù)的現(xiàn)象，但是會(huì)由于incr命令過(guò)得，導(dǎo)致重啟恢復(fù)數(shù)據(jù)時(shí)間過(guò)長(zhǎng)。

上述內(nèi)容就是互聯(lián)網(wǎng)的分布式ID的示例分析，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。