認(rèn)識“雪花ID”：如何在分布式環(huán)境中大規(guī)模生成唯一ID？

作者：佚名 2020-07-21 11:35:21

新聞

前端

分布式 唯一的ID使開發(fā)人員能夠正確識別、保存和檢索數(shù)據(jù)對象，并使數(shù)據(jù)對象參與到復(fù)雜的關(guān)系模式中。

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序設(shè)計、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了江孜免費建站歡迎大家使用！

圖源：unsplash

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

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

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

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

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

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

UUID樣本-版本4

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

分布式環(huán)境中生成唯一ID

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

持久層生成的ID

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

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

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

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

RDBMS vs代碼生成ID

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

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

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

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

圖源：unsplash

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

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

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

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

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

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

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

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

ID服務(wù)器生成ID

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

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

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

當(dāng)前題目：認(rèn)識“雪花ID”：如何在分布式環(huán)境中大規(guī)模生成唯一ID？
網(wǎng)頁地址：http://m.5511xx.com/article/cdghidh.html