[[334452]]

唯一的ID使開發(fā)人員能夠正確識(shí)別、保存和檢索數(shù)據(jù)對(duì)象，并使數(shù)據(jù)對(duì)象參與到復(fù)雜的關(guān)系模式中。在應(yīng)用程序開發(fā)周期中，程序員總會(huì)遇到要處理生成唯一的標(biāo)識(shí)符這項(xiàng)任務(wù)。

這些獨(dú)特的ID是如何生成的呢？哪種方法在不同的負(fù)載規(guī)模下最有效？ID如何在多個(gè)計(jì)算節(jié)點(diǎn)競爭下一個(gè)可用ID的分布式環(huán)境中保持唯一性？從小型單節(jié)點(diǎn)，到Twitter級(jí)別，本文筆者就將介紹三種最常見的技術(shù)。

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

通用唯一標(biāo)識(shí)符（UUID）這個(gè)概念大家不會(huì)陌生，它在軟件中已經(jīng)使用多年了。它是一個(gè)128位的數(shù)字，以受控和標(biāo)準(zhǔn)化的方式生成時(shí)，能夠提供非常大的鍵空間，幾乎消除了沖突的可能性。

UUID是由幾個(gè)不同部分組成的合成ID，例如時(shí)間、節(jié)點(diǎn)的MAC地址或MD5散列的命名空間。為了適應(yīng)所有這些組合，多年來，UUID規(guī)格已經(jīng)發(fā)展出多個(gè)版本，特別是版本1和版本4。

根據(jù)數(shù)據(jù)和業(yè)務(wù)域的不同，一些開發(fā)人員可能會(huì)對(duì)其他版本感興趣。處理128位數(shù)字并不是最適合開發(fā)人員描述信息的方式，因此UUID通常以規(guī)范文本形式表示，其中16個(gè)八位字節(jié)轉(zhuǎn)換為32個(gè)十六進(jìn)制字符，用連字符分隔，總共36個(gè)字符：

UUID最有趣的特性是其可以單獨(dú)生成，且仍能保證在分布式環(huán)境中的唯一性?；镜腎D生成算法并不復(fù)雜，也不需要任何同步（至少是低至100納秒級(jí)別），可以并行執(zhí)行：

能夠自生成唯一性的內(nèi)在屬性，使得UUID成為分布式環(huán)境中最常用的ID生成技術(shù)之一。但UUID需要額外的存儲(chǔ)空間，這可能會(huì)對(duì)查詢性能產(chǎn)生負(fù)面影響。

持久層生成的ID

如果不想在應(yīng)用程序級(jí)別生成唯一ID時(shí)，另一種常見的方法是用永續(xù)性儲(chǔ)存體來處理。

最近所有的RDBMS都提供了某種列數(shù)據(jù)類型，開發(fā)人員能夠委托它們生成唯一標(biāo)識(shí)符。MongoDB提供ObjectID，MySQL和MariaDB提供AUTO_INCREMENT，MS-SQL-Server提供IDENTITY，等等。執(zhí)行不同的數(shù)據(jù)庫，ID的實(shí)際表現(xiàn)會(huì)有所不同，但唯一性的含義保持不變。

持久層生成的ID緩解了必須在應(yīng)用程序代碼中生成唯一ID的問題。但如果操作一個(gè)大型數(shù)據(jù)庫集群，且有非常繁忙的應(yīng)用程序在前，這種方法可能就無法滿足需要了。

還有另一個(gè)問題：如果不往返數(shù)據(jù)庫，則生成的ID對(duì)于代碼來說是未知的：

RDBMS vs代碼生成ID

上圖中，額外往返于RDBMS可能會(huì)減慢應(yīng)用程序的速度，可能使代碼不必要地復(fù)雜化。然而，無論使用的是否是基礎(chǔ)RDBMS產(chǎn)品，現(xiàn)代ORM框架都有助于以標(biāo)準(zhǔn)化的方式完成這項(xiàng)工作。

ID服務(wù)器還是Snowflake ID

ID服務(wù)器負(fù)責(zé)為分布式基礎(chǔ)設(shè)施生成唯一的ID。根據(jù)ID服務(wù)器執(zhí)行功能的不同，可以是創(chuàng)建ID的單個(gè)服務(wù)器，也可以是每秒創(chuàng)建大量ID的服務(wù)器集群。

Twitter就不用我介紹了吧，平均每秒有9000條推特產(chǎn)生，峰值高達(dá)每秒143199條。Twitter需要一個(gè)解決方案，擴(kuò)大其龐大服務(wù)器基礎(chǔ)設(shè)施的規(guī)模，生成高效的存儲(chǔ)ID。

這就是Twitter推出Snowflake計(jì)劃的原因：Snowflake是一種能大規(guī)模生成唯一ID號(hào)的網(wǎng)絡(luò)服務(wù)，同時(shí)具備一些基礎(chǔ)的保證。

Twitter之前使用過一種每個(gè)進(jìn)程每秒至少生成10000個(gè)ID且響應(yīng)速度小于2ms的服務(wù)器。ID服務(wù)器之間不需要任何網(wǎng)絡(luò)協(xié)調(diào)，生成的ID應(yīng)大致按時(shí)間順序排列，為了將存儲(chǔ)保持在最低限度，生成的ID必須緊湊。

為了解決上述項(xiàng)目，Twitter開發(fā)了Snowflake項(xiàng)目作為用Scala編寫的Thrift服務(wù)器。生成的ID包括：

· 時(shí)間——41位（毫秒精度）

· 配置的機(jī)器ID——10位

· 序列號(hào)——12位（每臺(tái)機(jī)器每4096轉(zhuǎn)一次）

雖然現(xiàn)在Snowflake項(xiàng)目已經(jīng)結(jié)束，以一個(gè)更廣泛的項(xiàng)目TwitterServer取而代之，但是分布式ID生成器工作的基本原則仍然適用。由于每個(gè)生成器具有獨(dú)立性，Twitter能夠根據(jù)需要擴(kuò)展其基礎(chǔ)設(shè)施，不會(huì)產(chǎn)生由于集群同步和協(xié)調(diào)而造成額外的延遲。

使用ID服務(wù)器的解決方案與代碼生成ID的運(yùn)作方式類似：

你會(huì)發(fā)現(xiàn)，其性能仍然會(huì)由于往返于ID服務(wù)器而降低，但因?yàn)椴簧婕皬?fù)雜的數(shù)據(jù)庫操作，這一額外的延遲比將對(duì)象刷新到RDBMS要短得多。ID服務(wù)器提供了一個(gè)中間解決方案，使開發(fā)人員能夠控制生成唯一ID的方式與地點(diǎn)，無需引入復(fù)雜的、導(dǎo)致高延遲的基礎(chǔ)設(shè)施。

對(duì)于最終需要保存數(shù)據(jù)的所有應(yīng)用程序來說，生成唯一標(biāo)識(shí)符都是必要步驟。本文討論了三種常用的方法：UUID——本地生成ID，持久層驅(qū)動(dòng)ID——集中創(chuàng)建ID，以及SnowflakeID——作為網(wǎng)絡(luò)服務(wù)生成ID。

沒有一勞永逸的解決方案。在應(yīng)用程序中，選擇生成唯一ID的方法需要考慮數(shù)據(jù)、持久性選項(xiàng)和網(wǎng)絡(luò)基礎(chǔ)設(shè)施等各個(gè)方面，這樣才能挑到符合你需求和想法規(guī)模的方案。