摘要：為什么需要發(fā)號(hào)器在分布式系統(tǒng)中，經(jīng)常需要對(duì)大量的數(shù)據(jù)消息請(qǐng)求等進(jìn)行唯一標(biāo)識(shí)，例如對(duì)于分布式系統(tǒng)，服務(wù)間相互調(diào)用需要唯一標(biāo)識(shí)，調(diào)用鏈路分析，日志追蹤的時(shí)候需要使用這個(gè)唯一標(biāo)識(shí)。

原文鏈接：何曉東 博客

文章起源于 康神交流群的 panda大佬和boss li關(guān)于發(fā)號(hào)器的一些交流，特此感謝讓我們學(xué)到了新知識(shí)。

在分布式系統(tǒng)中，經(jīng)常需要對(duì)大量的數(shù)據(jù)、消息、http 請(qǐng)求等進(jìn)行唯一標(biāo)識(shí)，例如：對(duì)于分布式系統(tǒng)，服務(wù)間相互調(diào)用需要唯一標(biāo)識(shí)，調(diào)用鏈路分析，日志追蹤的時(shí)候需要使用這個(gè)唯一標(biāo)識(shí)。此時(shí)需要一個(gè)全局唯一的 ID。

持久化

要滿足長(zhǎng)期全局唯一，持久化是必須的，肯定不能讓已經(jīng)使用的再次產(chǎn)生一遍，同時(shí)需要強(qiáng)一致性?？捎眠x擇存儲(chǔ)在 Redis 或者 Etcd 中。

高可用

這個(gè)時(shí)候需要提供發(fā)號(hào)器服務(wù)的機(jī)器主從同步，能夠在主服務(wù)器宕機(jī)的時(shí)候，自動(dòng)選擇從服務(wù)器，切換過(guò)程中，發(fā)號(hào)器生成的 ID 可能不連續(xù)，服務(wù)正常就可以。

其他特性

主要是看具體業(yè)務(wù)了，需要認(rèn)證和權(quán)限控制都是可選的，可用在請(qǐng)求層限制來(lái)源 IP,只允許固定的 IP 訪問(wèn)。

UUID

UUID 是 Universally Unique Identifier 的縮寫(xiě)，它是在一定的范圍內(nèi)(從特定的名字空間到全球)唯一的機(jī)器生成的標(biāo)識(shí)符，UUID 是16字節(jié)128位長(zhǎng)的數(shù)字，通常以36字節(jié)的字符串表示，比如：3F2504E0-4F89-11D3-9A0C-0305E82C3301。

UUID經(jīng)由一定的算法機(jī)器生成，為了保證 UUID 的唯一性，規(guī)范定義了包括網(wǎng)卡 MAC 地址、時(shí)間戳、名字空間(Namespace)、隨機(jī)或偽隨機(jī)數(shù)、時(shí)序等元素，以及從這些元素生成 UUID 的算法。UUID 的復(fù)雜特性在保證了其唯一性的同時(shí)，意味著只能由計(jì)算機(jī)生成。

優(yōu)缺點(diǎn)： 本地生成，性能高，延遲低，位數(shù)長(zhǎng)，不適用當(dāng)作索引字段，同時(shí)是無(wú)序的，難以根據(jù)特征分析趨勢(shì)。

類(lèi)snowflake算法

snowflake是twitter開(kāi)源的分布式ID生成算法，其核心思想為，一個(gè)long型的ID：

41bit作為毫秒數(shù) - 10bit作為機(jī)器編號(hào) - 12bit作為毫秒內(nèi)序列號(hào)

算法單機(jī)每秒內(nèi)理論上最多可以生成1000*(2^12)，也就是400W的ID，

優(yōu)缺點(diǎn)： 整個(gè) ID 都是自增的，這個(gè)非常適合查看趨勢(shì)，同時(shí)生成不依賴于第三方系統(tǒng)，可靠性很高，可調(diào)整性也很高。缺點(diǎn)就是嚴(yán)重依賴機(jī)器時(shí)鐘。

基于MySQL的發(fā)號(hào)器

字段設(shè)置 auto_increment_increment 和 auto_increment_offset 來(lái)保證 ID 自增，每次業(yè)務(wù)使用下列 SQL 讀寫(xiě) MySQL 得到 ID。

begin;
REPLACE INTO Tickets64 (stub) VALUES ("a");
SELECT LAST_INSERT_ID();
commit;

為了保證高可用，需要有多臺(tái) MySQL 機(jī)器，也需要為每臺(tái)機(jī)器設(shè)置不同的自增起始值和步長(zhǎng)，例如：

# TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

# TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

優(yōu)缺點(diǎn)： 簡(jiǎn)單可靠，成本很小，由專業(yè) DBA 進(jìn)行維護(hù)就可以的。ID 單調(diào)遞增，有合適的業(yè)務(wù)是最好的。缺點(diǎn)就是強(qiáng)依賴于數(shù)據(jù)庫(kù)，修改起點(diǎn)和步長(zhǎng)優(yōu)點(diǎn)困難，同時(shí)也需要額外保證數(shù)據(jù)庫(kù)的穩(wěn)定可用。每次請(qǐng)求都去額外讀寫(xiě)數(shù)據(jù)庫(kù)的情況下，造成數(shù)據(jù)庫(kù)壓力很大，需要消耗很多資源。

以上就是最常用的三種全局唯一 ID 生成方案，采用較多的是類(lèi) snowflake 的方案，如果請(qǐng)求數(shù)列不是很高，可以調(diào)低時(shí)間的精度等，靈活性很高。生成的 ID 時(shí)間趨勢(shì)自增，甚至可以用來(lái)做索引字段，占用空間較小。后期對(duì)數(shù)據(jù)進(jìn)行分析的時(shí)候也很方便。

類(lèi) snowflake 的方案，會(huì)采用請(qǐng)求時(shí)生成的方式，無(wú)法提前生成。

基于 MySQL 的發(fā)號(hào)器，或者 uuid 模式的，可用提前生成一大批數(shù)據(jù)，根據(jù)業(yè)務(wù)去定生成數(shù)量，放到內(nèi)存，MQ 或者 Redis List中，業(yè)務(wù)申請(qǐng)唯一 ID 的時(shí)候，直接從其中彈一個(gè)出來(lái)。同時(shí)加一個(gè)異步定時(shí)任務(wù)，固定時(shí)間計(jì)算一下隊(duì)列中剩余的唯一 ID 數(shù)量，數(shù)量不足時(shí)及時(shí)的再次生成一大批，加入到備選隊(duì)列。

Go snowflake的demo:

參考文章：

有贊技術(shù)團(tuán)隊(duì)文章 - 發(fā)號(hào)器

CSDN文章

美團(tuán)分布式ID生成

Go snowflake包

一如既往，推薦幾個(gè) 高質(zhì)量課程，你學(xué)到新東西，我賺點(diǎn)傭金，大家都是贏家。