UUID算法分析:如何保證唯一性

UUID具有以下涵義:

經由一定的算法機器生成
爲了保證UUID的唯一性,規範定義了包括網卡MAC地址、時間戳、名字空間(Namespace)、隨機或僞隨機數、時序等元素,以及從這些元素生成UUID的算法。UUID的複雜特性在保證了其唯一性的同時,意味着只能由計算機生成。

非人工指定,非人工識別
UUID是不能人工指定的,除非你冒着UUID重複的風險。UUID的複雜性決定了“一般人“不能直接從一個UUID知道哪個對象和它關聯。

在特定的範圍內重複的可能性極小
UUID的生成規範定義的算法主要目的就是要保證其唯一性。但這個唯一性是有限的,只在特定的範圍內才能得到保證,這和UUID的類型有關(參見UUID的版本)。

UUID的版本

UUID具有多個版本,每個版本的算法不同,應用範圍也不同。
首先是一個特例--Nil UUID--通常我們不會用到它,它是由全爲0的數字組成,如下:
00000000-0000-0000-0000-000000000000

UUID Version 1:基於時間的UUID
基於時間的UUID通過計算當前時間戳、隨機數和機器MAC地址得到。由於在算法中使用了MAC地址,這個版本的UUID可以保證在全球範圍的唯一性。但與此同時,使用MAC地址會帶來安全性問題,這就是這個版本UUID受到批評的地方。如果應用只是在局域網中使用,也可以使用退化的算法,以IP地址來代替MAC地址--Java的UUID往往是這樣實現的(當然也考慮了獲取MAC的難度)。

UUID Version 2:DCE安全的UUID
DCE(Distributed Computing Environment)安全的UUID和基於時間的UUID算法相同,但會把時間戳的前4位置換爲POSIX的UID或GID。這個版本的UUID在實際中較少用到。

UUID Version 3:基於名字的UUID(MD5)
基於名字的UUID通過計算名字和名字空間的MD5散列值得到。這個版本的UUID保證了:相同名字空間中不同名字生成的UUID的唯一性;不同名字空間中的UUID的唯一性;相同名字空間中相同名字的UUID重複生成是相同的。

UUID Version 4:隨機UUID
根據隨機數,或者僞隨機數生成UUID。這種UUID產生重複的概率是可以計算出來的,但隨機的東西就像是買彩票:你指望它發財是不可能的,但狗屎運通常會在不經意中到來。

UUID Version 5:基於名字的UUID(SHA1)
和版本3的UUID算法類似,只是散列值計算使用SHA1(Secure Hash Algorithm 1)算法。

UUID的應用

從UUID的不同版本可以看出,
Version 1/2適合應用於分佈式計算環境下,具有高度的唯一性;
Version 3/5適合於一定範圍內名字唯一,且需要或可能會重複生成UUID的環境下;
至於Version 4,個人的建議是最好不用(雖然它是最簡單最方便的)。
通常我們建議使用UUID來標識對象或持久化數據,但以下情況最好不使用UUID:
映射類型的對象。比如只有代碼及名稱的代碼表。
人工維護的非系統生成對象。比如系統中的部分基礎數據。
對於具有名稱不可重複的自然特性的對象,最好使用Version 3/5的UUID。比如系統中的用戶。如果用戶的UUID是Version 1的,如果你不小心刪除了再重建用戶,你會發現人還是那個人,用戶已經不是那個用戶了。(雖然標記爲刪除狀態也是一種解決方案,但會帶來實現上的複雜性。)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章