在后端系統(tǒng)中，每條記錄都需要一個(gè)唯一的ID來(lái)進(jìn)行標(biāo)識(shí)。

雖然一開(kāi)始聽(tīng)起來(lái)可能很瑣碎，但在高度分布式的環(huán)境中生成全局唯一標(biāo)識(shí)符實(shí)際上是一個(gè)具有挑戰(zhàn)性的任務(wù)。

在本文中，讓我們來(lái)看一下一些常見(jiàn)的已知ID生成算法。

Ticket 服務(wù) - 集中式數(shù)據(jù)庫(kù)

使用自增功能生成ID

Ticket 服務(wù)解決方案利用 SQL 數(shù)據(jù)庫(kù)中的自增功能來(lái)生成唯一的ID。

使用集中式數(shù)據(jù)庫(kù)服務(wù)器，Web 服務(wù)器插入一個(gè)新記錄到數(shù)據(jù)庫(kù)中以生成一個(gè)自增的ID。

CREATE TABLE `ID` (
`id` bigint(20) unsigned NOT NULL auto_increment,
`stub` char(1) NOT NULL default '',
PRIMARY KEY (`id`),
UNIQUE KEY (stub)
);
REPLACE INTO ID (stub) VALUES ('a');
SELECT LAST_INSERT_ID();

與使用 INSERT INTO 命令不同，我們可以使用 REPLACE INTO 命令來(lái)減少數(shù)據(jù)庫(kù)中的記錄數(shù)量。

REPLACE INTO 命令以原子方式原地更新單行，并獲取自增的主 ID，而無(wú)需創(chuàng)建新記錄。

優(yōu)點(diǎn)：

• 實(shí)現(xiàn)簡(jiǎn)單
• 生成的ID是64位的
• ID是順序且可排序的

缺點(diǎn)：

• 只能使用1個(gè)表。多個(gè)表或數(shù)據(jù)庫(kù)將導(dǎo)致ID沖突
• 由于只使用了1個(gè)表，數(shù)據(jù)庫(kù)成為了單點(diǎn)故障
• 如果每秒的寫(xiě)入數(shù)量巨大，將會(huì)有寫(xiě)入瓶頸

Ticket 服務(wù) - 集群式數(shù)據(jù)庫(kù)

使用輪詢(xún)路由請(qǐng)求

與使用一個(gè)數(shù)據(jù)庫(kù)不同，我們可以使用多個(gè)具有偏移量的數(shù)據(jù)庫(kù)，以避免單點(diǎn)故障和寫(xiě)入瓶頸。

偏移量 用于防止ID沖突。每個(gè)數(shù)據(jù)庫(kù)通過(guò) k，k 是正在使用的數(shù)據(jù)庫(kù)服務(wù)器數(shù)量，增加其ID。

如上所示，如果使用了三個(gè)數(shù)據(jù)庫(kù)，每次生成ID時(shí)，自增的ID增加3。

優(yōu)點(diǎn)：

• 相對(duì)容易實(shí)現(xiàn)
• 生成的ID是64位的
• 能夠在沒(méi)有單點(diǎn)故障的情況下處理高吞吐量

缺點(diǎn)：

• 由于使用了多個(gè)數(shù)據(jù)庫(kù)，生成的ID不能保證是可排序的
• 難以水平擴(kuò)展。添加新數(shù)據(jù)庫(kù)很棘手，因?yàn)樗鼤?huì)影響偏移量。

Twitter Snowflake

Snowflake方法在不依賴(lài)數(shù)據(jù)庫(kù)的情況下生成 64位的ID。

64位的ID被分成5個(gè)主要部分

ID分為5個(gè)主要部分：

• 時(shí)間戳（41位）
• 數(shù)據(jù)中心ID（5位）
• 機(jī)器ID（5位）
• 序列號(hào)（12位）
• 符號(hào)位（1位）

時(shí)間戳。自紀(jì)元以來(lái)的毫秒數(shù)。41位大約會(huì)在70年內(nèi)溢出，對(duì)于大多數(shù)項(xiàng)目的壽命來(lái)說(shuō)是安全的。

數(shù)據(jù)中心ID。服務(wù)器所在的數(shù)據(jù)中心。如果兩個(gè)服務(wù)器在相同的時(shí)間收到相同的請(qǐng)求，則可以防止ID沖突。

機(jī)器ID。機(jī)器的ID。如果兩臺(tái)服務(wù)器在相似的數(shù)據(jù)中心中的相同時(shí)間收到相同的請(qǐng)求，則可以防止沖突。

序列號(hào)。對(duì)于在同一服務(wù)器上生成的每個(gè)ID，序列號(hào)會(huì)遞增1，并在每毫秒重置為0。這可以防止在同一服務(wù)器上的ID沖突。

優(yōu)點(diǎn)：

• ID大致是有序的
• 能夠在沒(méi)有單點(diǎn)故障的情況下處理高吞吐量
• 能夠在機(jī)器之間無(wú)需協(xié)調(diào)地生成ID
• 能夠水平擴(kuò)展。

缺點(diǎn)：

• ID不是完全有序的
• 未來(lái)的ID是可預(yù)測(cè)的。對(duì)于安全要求較高的應(yīng)用程序可能不理想
• 需要一個(gè)Zookeeper來(lái)跟蹤機(jī)器ID。

MongoDB ObjectID

MongoDB為每個(gè)新文檔創(chuàng)建一個(gè)唯一的對(duì)象ID。

對(duì)象ID由 MongoDB驅(qū)動(dòng)程序生成而不是數(shù)據(jù)庫(kù)。這意味著可以在服務(wù)器上生成對(duì)象ID，而不依賴(lài)于MongoDB數(shù)據(jù)庫(kù)。

MongoDB對(duì)象ID是一個(gè)96位的ID

與Snowflake方法類(lèi)似，MongoDB對(duì)象ID分為4個(gè)部分。對(duì)象ID是一個(gè)96位的ID。

• 時(shí)間戳（32位）
• 機(jī)器ID（24位）
• 進(jìn)程ID（16位）
• 計(jì)數(shù)器（24位）

大部分字段與Snowflake方法中提到的字段相似。

由于同一臺(tái)機(jī)器上可能運(yùn)行多個(gè)線(xiàn)程或進(jìn)程，因此進(jìn)程ID可以區(qū)分在不同進(jìn)程中由同一臺(tái)機(jī)器生成的對(duì)象ID。

優(yōu)點(diǎn)：

• 能夠在沒(méi)有單點(diǎn)故障的情況下處理高吞吐量
• 能夠在機(jī)器之間無(wú)需協(xié)調(diào)地生成ID
• 能夠水平擴(kuò)展。

缺點(diǎn)：

• 依賴(lài)第三方數(shù)據(jù)庫(kù)解決方案
• ID的長(zhǎng)度為96位，而不是64位，需要更多的存儲(chǔ)空間。

UUID（通用唯一標(biāo)識(shí)符）

128位UUID的示例

通用唯一標(biāo)識(shí)符是一個(gè)128位的數(shù)字，包括多個(gè)部分，例如時(shí)間、節(jié)點(diǎn)的MAC地址或MD5哈希的命名空間。

有一組標(biāo)準(zhǔn)化的算法用于生成UUID，多年來(lái)已經(jīng)發(fā)布了5個(gè)不同版本的UUID，以適應(yīng)不同的需求。

這些算法相當(dāng)冗長(zhǎng)，因此我們不會(huì)詳細(xì)介紹它們。我們將更多地關(guān)注它的優(yōu)缺點(diǎn)。

優(yōu)點(diǎn)：

• 它是一個(gè)128位的ID，保證是唯一的
• 可以獨(dú)立生成，無(wú)需依賴(lài)任何第三方服務(wù)
• 它是隨機(jī)的和安全的。下一個(gè)ID是不可預(yù)測(cè)的。

缺點(diǎn)：

• 它很大，在MySQL中索引不佳
• 它不是有序的

結(jié)論

在分布式環(huán)境中實(shí)現(xiàn)高度可擴(kuò)展和可用的ID生成器并不是微不足道的。