[[334452]]

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

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

通用唯一標識符——UUID

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

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

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

UUID最有趣的特性是其可以單獨生成，且仍能保證在分布式環境中的唯一性。基本的ID生成算法并不復雜，也不需要任何同步（至少是低至100納秒級別），可以并行執行：

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

持久層生成的ID

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

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

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

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

RDBMS vs代碼生成ID

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

ID服務器還是Snowflake ID

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

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

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

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

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

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

· 配置的機器ID——10位

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

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

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

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

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

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