[[334452]]

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

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

通用唯一標識符——UUID

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

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

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

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

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

持久層生成的ID

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

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

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

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

RDBMS vs代碼生成ID

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

ID服務器還是Snowflake ID

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

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

這就是Twitter推出Snowflake計劃的原因：Snowflake是一種能大規(guī)模生成唯一ID號的網(wǎng)絡服務，同時具備一些基礎的保證。

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

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

· 時間——41位（毫秒精度）

· 配置的機器ID——10位

· 序列號——12位（每臺機器每4096轉一次）

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

使用ID服務器的解決方案與代碼生成ID的運作方式類似：

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

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

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