概述
系統(tǒng)唯一ID是我們?cè)谠O(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候常常會(huì)遇見(jiàn)的問(wèn)題，也常常為這個(gè)問(wèn)題而糾結(jié)。生成ID的方法有很多，適應(yīng)不同的場(chǎng)景、需求以及性能要求。所以有些比較復(fù)雜的系統(tǒng)會(huì)有多個(gè)ID生成的策略。
分布式ID的特性
- 唯一性：確保生成的ID是全網(wǎng)唯一的。
- 有序遞增性：確保生成的ID是對(duì)于某個(gè)用戶(hù)或者業(yè)務(wù)是按一定的數(shù)字有序遞增的。
- 高可用性：確保任何時(shí)候都能正確的生成ID。
- 帶時(shí)間：ID里面包含時(shí)間，一眼掃過(guò)去就知道哪天的交易。
下面介紹幾種分布式ID的生成方案。
1、數(shù)據(jù)庫(kù)自增長(zhǎng)序列或字段
最常見(jiàn)的方式。利用數(shù)據(jù)庫(kù)，全數(shù)據(jù)庫(kù)唯一。
優(yōu)點(diǎn)：
1）簡(jiǎn)單，代碼方便，性能可以接受。 2）數(shù)字ID天然排序，對(duì)分頁(yè)或者需要排序的結(jié)果很有幫助。
缺點(diǎn)：
1）不同數(shù)據(jù)庫(kù)語(yǔ)法和實(shí)現(xiàn)不同，數(shù)據(jù)庫(kù)遷移的時(shí)候或多數(shù)據(jù)庫(kù)版本支持的時(shí)候需要處理。 2）在單個(gè)數(shù)據(jù)庫(kù)或讀寫(xiě)分離或一主多從的情況下，只有一個(gè)主庫(kù)可以生成。有單點(diǎn)故障的風(fēng)險(xiǎn)。 3）在性能達(dá)不到要求的情況下，比較難于擴(kuò)展。 4）如果遇見(jiàn)多個(gè)系統(tǒng)需要合并或者涉及到數(shù)據(jù)遷移會(huì)相當(dāng)痛苦。 5）分表分庫(kù)的時(shí)候會(huì)有麻煩。
優(yōu)化方案：
針對(duì)主庫(kù)單點(diǎn)，如果有多個(gè)Master庫(kù)，則每個(gè)Master庫(kù)設(shè)置的起始數(shù)字不一樣，步長(zhǎng)一樣，可以是Master的個(gè)數(shù)。比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。這樣就可以有效生成集群中的唯一ID，也可以大大降低ID生成數(shù)據(jù)庫(kù)操作的負(fù)載。
2、UUID
常見(jiàn)的方式。可以利用數(shù)據(jù)庫(kù)也可以利用程序生成，一般來(lái)說(shuō)全球唯一。
優(yōu)點(diǎn)：
1）簡(jiǎn)單，代碼方便。 2）生成ID性能非常好，基本不會(huì)有性能問(wèn)題。 3）全球唯一，在遇見(jiàn)數(shù)據(jù)遷移，系統(tǒng)數(shù)據(jù)合并，或者數(shù)據(jù)庫(kù)變更等情況下，可以從容應(yīng)對(duì)。
缺點(diǎn)：
1）沒(méi)有排序，無(wú)法保證趨勢(shì)遞增。 2）UUID往往是使用字符串存儲(chǔ)，查詢(xún)的效率比較低。 3）存儲(chǔ)空間比較大，如果是海量數(shù)據(jù)庫(kù)，就需要考慮存儲(chǔ)量的問(wèn)題。 4）傳輸數(shù)據(jù)量大 5）不可讀。
3、批量生成ID
一次按需批量生成多個(gè)ID，每次生成都需要訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)，將數(shù)據(jù)庫(kù)修改為最大的ID值，并在內(nèi)存中記錄當(dāng)前值及最大值。
優(yōu)點(diǎn)：
避免了每次生成ID都要訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)并帶來(lái)壓力，提高性能
缺點(diǎn)：
屬于本地生成策略，存在單點(diǎn)故障，服務(wù)重啟造成ID不連續(xù)
4、redis生成ID
當(dāng)使用數(shù)據(jù)庫(kù)來(lái)生成ID性能不夠要求的時(shí)候，可以嘗試使用Redis來(lái)生成ID。這主要依賴(lài)于Redis是單線(xiàn)程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY來(lái)實(shí)現(xiàn)。
可以使用Redis集群來(lái)獲取更高的吞吐量。假如一個(gè)集群中有5臺(tái)Redis。可以初始化每臺(tái)Redis的值分別是1,2,3,4,5，然后步長(zhǎng)都是5。各個(gè)Redis生成的ID為：
A：1,6,11,16,21 B：2,7,12,17,22 C：3,8,13,18,23 D：4,9,14,19,24 E：5,10,15,20,25
這個(gè)，隨便負(fù)載到哪個(gè)機(jī)確定好，未來(lái)很難做修改。但是3-5臺(tái)服務(wù)器基本能夠滿(mǎn)足器上，都可以獲得不同的ID。但是步長(zhǎng)和初始值一定需要事先需要了。使用Redis集群也可以方式單點(diǎn)故障的問(wèn)題。
另外，比較適合使用Redis來(lái)生成每天從0開(kāi)始的流水號(hào)。比如訂單號(hào)=日期+當(dāng)日自增長(zhǎng)號(hào)。可以每天在Redis中生成一個(gè)Key，使用INCR進(jìn)行累加。
優(yōu)點(diǎn)：
1）不依賴(lài)于數(shù)據(jù)庫(kù)，靈活方便，且性能優(yōu)于數(shù)據(jù)庫(kù)。 2）數(shù)字ID天然排序，對(duì)分頁(yè)或者需要排序的結(jié)果很有幫助。
缺點(diǎn)：
1）如果系統(tǒng)中沒(méi)有Redis，還需要引入新的組件，增加系統(tǒng)復(fù)雜度。 2）需要編碼和配置的工作量比較大。
5、Twitter的snowflake算法（目前我們?cè)谑褂玫模?/strong>
snowflake是Twitter開(kāi)源的分布式ID生成算法，結(jié)果是一個(gè)long型的ID。雪花算法將生成不高于19位的有序Long型整數(shù)，多用于分布式環(huán)境的數(shù)據(jù)主鍵。
其核心思想是：使用41bit作為毫秒數(shù)，10bit作為機(jī)器的ID（5個(gè)bit是數(shù)據(jù)中心，5個(gè)bit的機(jī)器ID），12bit作為毫秒內(nèi)的流水號(hào)（意味著每個(gè)節(jié)點(diǎn)在每毫秒可以產(chǎn)生 4096 個(gè) ID），最后還有一個(gè)符號(hào)位，永遠(yuǎn)是0。
snowflake算法可以根據(jù)自身項(xiàng)目的需要進(jìn)行一定的修改。比如估算未來(lái)的數(shù)據(jù)中心個(gè)數(shù)，每個(gè)數(shù)據(jù)中心的機(jī)器數(shù)以及統(tǒng)一毫秒可以能的并發(fā)數(shù)來(lái)調(diào)整在算法中所需要的bit數(shù)。
優(yōu)點(diǎn)：
1）不依賴(lài)于數(shù)據(jù)庫(kù)，靈活方便，且性能優(yōu)于數(shù)據(jù)庫(kù)。 2）ID按照時(shí)間在單機(jī)上是遞增的。
缺點(diǎn)：
在單機(jī)上是遞增的，但是由于涉及到分布式環(huán)境，每臺(tái)機(jī)器上的時(shí)鐘不可能完全同步，也許有時(shí)候也會(huì)出現(xiàn)不是全局遞增的情況。
6、利用zookeeper生成唯一ID
zookeeper主要通過(guò)其znode數(shù)據(jù)版本來(lái)生成序列號(hào)，可以生成32位和64位的數(shù)據(jù)版本號(hào)，客戶(hù)端可以使用這個(gè)版本號(hào)來(lái)作為唯一的序列號(hào)。
很少會(huì)使用zookeeper來(lái)生成唯一ID。主要是由于需要依賴(lài)zookeeper，并且是多步調(diào)用API，如果在競(jìng)爭(zhēng)較大的情況下，需要考慮使用分布式鎖。因此，性能在高并發(fā)的分布式環(huán)境下，也不甚理想。
7、 MongoDB的ObjectId
MongoDB的ObjectId和snowflake算法類(lèi)似。它設(shè)計(jì)成輕量型的，不同的機(jī)器都能用全局唯一的同種方法方便地生成它。MongoDB 從一開(kāi)始就設(shè)計(jì)用來(lái)作為分布式數(shù)據(jù)庫(kù)，處理多個(gè)節(jié)點(diǎn)是一個(gè)核心要求。使其在分片環(huán)境中要容易生成得多。
MongoDB 中我們經(jīng)常會(huì)接觸到一個(gè)自動(dòng)生成的字段："_id"，類(lèi)型為ObjectId。
之前我們使用MySQL等關(guān)系型數(shù)據(jù)庫(kù)時(shí)，主鍵都是設(shè)置成自增的。但在分布式環(huán)境下，這種方法就不可行了，會(huì)產(chǎn)生沖突。為此，mongodb采用了一個(gè)稱(chēng)之為ObjectId的類(lèi)型來(lái)做主鍵。ObjectId是一個(gè)12字節(jié)的 BSON 類(lèi)型字符串。按照字節(jié)順序，一次代表：
- 4字節(jié)：UNIX時(shí)間戳
- 3字節(jié)：表示運(yùn)行MongoDB的機(jī)器
- 2字節(jié)：表示生成此_id的進(jìn)程
- 3字節(jié)：由一個(gè)隨機(jī)數(shù)開(kāi)始的計(jì)數(shù)器生成的值
為了確保在同一臺(tái)機(jī)器上并發(fā)的多個(gè)進(jìn)程產(chǎn)生的ObjectId 是唯一的，接下來(lái)的兩字節(jié)來(lái)自產(chǎn)生ObjectId 的進(jìn)程標(biāo)識(shí)符（PID）。
ObjetId的12字節(jié)
前9 字節(jié)保證了同一秒鐘不同機(jī)器不同進(jìn)程產(chǎn)生的ObjectId 是唯一的。后3 字節(jié)就是一個(gè)自動(dòng)增加的計(jì)數(shù)器，確保相同進(jìn)程同一秒產(chǎn)生的ObjectId 也是不一樣的。同一秒鐘最多允許每個(gè)進(jìn)程擁有2563（16777216）個(gè)不同的ObjectId。
