在《悟空傳》篇外篇里，有一個(gè)憂傷的故事。

秋天，樹上掉下兩片葉子，你要和它們說再見。但你如何知道這片葉子，不是另外一片葉子？是通過它的形狀，還是通過它的重量？

當(dāng)我們?cè)诜植际江h(huán)境中存儲(chǔ)一些數(shù)據(jù)的時(shí)候，不得不面對(duì)的一個(gè)選擇，就是ID生成器。

使用一個(gè)唯一的字符串，來標(biāo)識(shí)一條完整的記錄。

這時(shí)候，不能使用md5或者sha1來對(duì)整個(gè)記錄做摘要，因?yàn)槲覀兒罄m(xù)還要改動(dòng)這個(gè)記錄。也不能使用單機(jī)的計(jì)數(shù)器，因?yàn)橛?jì)數(shù)器容易重啟清零，也會(huì)存在多臺(tái)機(jī)器上的數(shù)值重復(fù)，這違背了無狀態(tài)服務(wù)的建設(shè)目標(biāo)。

無奈的選擇UUID

雖然UUID在大多數(shù)語言中都有相關(guān)的類庫，但除非破不得以，我們一般不會(huì)使用它。UUID雖然不會(huì)重復(fù)，但它非常的長，長的讓人望而生畏。

XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

標(biāo)準(zhǔn)的UUID有5個(gè)部分組成：8-4-4-4-12，一共32個(gè)十六進(jìn)制字符。因此，一共是128位。

當(dāng)把UUID作為數(shù)據(jù)庫的索引時(shí)，會(huì)因?yàn)樗鼪]有順序性造成索引的隨機(jī)分布和；因?yàn)閿?shù)據(jù)量巨大造成查詢性能降低。

同時(shí)，UUID也是不可讀的。如果你把它打印在紙質(zhì)的訂單上，并不是一個(gè)好的主意。

UUID同時(shí)還有信息安全的隱患，它的數(shù)據(jù)計(jì)算里有MAC地址的參與，比較知名的是，曾被用于尋找梅麗莎病毒的制作者位置。

改造時(shí)間戳

如果你是單機(jī)應(yīng)用，那么使用時(shí)間戳沒什么問題，即使不用納秒，使用毫秒也是足夠的。但在分布式環(huán)境下面，時(shí)間戳同樣不是一個(gè)好的選擇。

即使你在機(jī)器安裝了ntpd時(shí)間同步，但由于網(wǎng)絡(luò)和機(jī)器的差異，計(jì)算機(jī)的時(shí)鐘總是存在差異，你的時(shí)間戳總會(huì)出現(xiàn)重復(fù)。為了解決這個(gè)問題，你需要增加一些其他的標(biāo)識(shí)，比如機(jī)器的ID，或者更多細(xì)分的信息減少時(shí)間的碰撞。

這種自定義的ID生成器，只適合特定的業(yè)務(wù)。

做著做著你就會(huì)發(fā)現(xiàn)，它本質(zhì)上是雪花算法的變種。

雪花算法

雪花算法生成的ID是long類型，默認(rèn)字符串長度是19位，它分為4個(gè)部分。

• 保留位 1 位。
• 毫秒時(shí)間戳 — 41 位（比如從現(xiàn)在開始，支持到未來的69年）,這個(gè)其實(shí)也挺尷尬的，因?yàn)?0年之后就會(huì)失效。但你不會(huì)在一家公司工作70年，所以，隨它去吧。
• 配置的機(jī)器/節(jié)點(diǎn)/分片 ID — 10 位（總共支持 2^10 = 1024 個(gè)節(jié)點(diǎn)）
• 序列號(hào) - 12 位（機(jī)器的本地計(jì)數(shù)，所以支持的并發(fā)已經(jīng)很高了）

相比起UUID來，雪花算法所生成的ID是排序的，具有更好的緊湊性，是目前大多數(shù)業(yè)務(wù)優(yōu)先采用的ID生成算法。

值得注意的是，雪花算法在JavaScript中有一個(gè)坑。后端在返回ID的時(shí)候，需要使用String類型代替Long類型，否則會(huì)產(chǎn)生預(yù)想不到的錯(cuò)誤。

這是因?yàn)椤Ｔ贘avaScript中，存在兩種數(shù)字。Number和BigInt。最常用的，就是number。

最大的Number，叫做Number.MAX_SAFE_INTEGER，它的值為：

• 2^53-1 或者
• +/- 9,007,199,254,740,991

眾所周知，Java中的Long，是64位的。Js中的這個(gè)安全I(xiàn)nteger，完全達(dá)不到Java中定義的長度。

這就是萬惡的IEEE_754規(guī)范，它在Long長度大于17位時(shí)會(huì)出現(xiàn)精度丟失的問題。

NanoID

NanoID是從JavaScript庫中演變過來的，目前在多個(gè)語言上通用。它長下面這樣。

V1StGXR8_Z5jdHi6B-myT

雖然NanoID無法替代雪花算法，但就憑這長度，替換UUID是綽綽有余的。NanoID 大小只有 108 字節(jié)，比UUID小了35%，更加緊湊。

另外，它的速度更快，它可以使用默認(rèn)字母表每秒生成超過 220 萬個(gè)唯一 ID，使用自定義字母表時(shí)每秒可以生成超過 180 萬個(gè)唯一 ID，且?guī)缀鯖]有碰撞幾率。

如果你的ID對(duì)順序性沒有什么嚴(yán)格的要求，比如使用了kv等非常松散的數(shù)據(jù)庫，那么NanoID是你的不二選擇。

介紹了這么多，你會(huì)用哪種ID生成器呢？其實(shí)，一個(gè)組件如果使用的量增加到一定程度，都會(huì)出現(xiàn)問題，需要專門進(jìn)行組件設(shè)計(jì)。

比如美團(tuán)的leaf，在大型互聯(lián)網(wǎng)中肯定有用武之地。但對(duì)于一般互聯(lián)網(wǎng)，甚至是中型互聯(lián)網(wǎng)來說，這到底是躺椅還是炮彈，作為決策者的你不得不思量思量。

作者簡介：小姐姐味道  (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。