潛魚在淵

          Concentrating on Architectures.

          posts - 77, comments - 309, trackbacks - 0, articles - 0
            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

          深入解析UUID及其應用

          Posted on 2008-10-14 22:52 非魚 閱讀(20523) 評論(3)  編輯  收藏 所屬分類: 面向對象設計Java技術
          討論UUID的定義、分類、應用及生成工具。

          什么是UUID?

          UUID是Universally Unique Identifier的縮寫,它是在一定的范圍內(從特定的名字空間到全球)唯一的機器生成的標識符。UUID具有以下涵義:

          • 經由一定的算法機器生成
          為了保證UUID的唯一性,規范定義了包括網卡MAC地址、時間戳、名字空間(Namespace)、隨機或偽隨機數、時序等元素,以及從這些元素生成UUID的算法。UUID的復雜特性在保證了其唯一性的同時,意味著只能由計算機生成。
          • 非人工指定,非人工識別
          UUID是不能人工指定的,除非你冒著UUID重復的風險。UUID的復雜性決定了“一般人“不能直接從一個UUID知道哪個對象和它關聯。
          • 在特定的范圍內重復的可能性極小
          UUID的生成規范定義的算法主要目的就是要保證其唯一性。但這個唯一性是有限的,只在特定的范圍內才能得到保證,這和UUID的類型有關(參見UUID的版本)。

          UUID是16字節128位長的數字,通常以36字節的字符串表示,示例如下:

          3F2504E0-4F89-11D3-9A0C-0305E82C3301

          其中的字母是16進制表示,大小寫無關。

          GUID(Globally Unique Identifier)是UUID的別名;但在實際應用中,GUID通常是指微軟實現的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的,如果你不小心刪除了再重建用戶,你會發現人還是那個人,用戶已經不是那個用戶了。(雖然標記為刪除狀態也是一種解決方案,但會帶來實現上的復雜性。)

          UUID生成器

          我沒想著有人看完了這篇文章就去自己實現一個UUID生成器,所以前面的內容并不涉及算法的細節。下面是一些可用的Java UUID生成器:

          • Java UUID Generator (JUG):開源UUID生成器,LGPL協議,支持MAC地址。
          • UUID:特殊的License,有源碼。
          • Java 5以上版本中自帶的UUID生成器:好像只能生成Version 3/4的UUID。
          此外,Hibernate中也有一個UUID生成器,但是,生成的不是任何一個(規范)版本的UUID,強烈不建議使用。

          延伸閱讀

          UUID規范:rfc4122
          DCE 1.1中的UUID

          ,


          評論

          # re: 深入解析UUID及其應用[未登錄]  回復  更多評論   

          2008-10-15 20:03 by apple0668
          UUID有它的優勢,不過如果查詢的話,字符串還是要考慮到效率問題。比較查詢的話,按照id查詢如果是數字,效率應該比字符串要高。

          # re: 深入解析UUID及其應用  回復  更多評論   

          2008-10-20 09:59 by andylin
          轉載了您的這篇文章。
          地址:http://blog.csdn.net/andylin02/archive/2008/10/20/3108876.aspx

          # re: 深入解析UUID及其應用  回復  更多評論   

          2009-04-23 22:28 by MarchCuckoo
          轉載您的這篇文章。謝謝了!


          地址:http://user.qzone.qq.com/295446401/infocenter?ptlang=2052
          主站蜘蛛池模板: 延庆县| 烟台市| 民乐县| 商丘市| 鲁甸县| 黎城县| 大洼县| 绍兴市| 长泰县| 南阳市| 九江县| 孟津县| 周宁县| 祁阳县| 大安市| 新源县| 巫溪县| 嵊州市| 台东县| 金寨县| 内丘县| 余干县| 汉沽区| 荣成市| 临洮县| 读书| 大新县| 余干县| 马龙县| 永宁县| 靖宇县| 蚌埠市| 青田县| 嘉鱼县| 泗水县| 南汇区| 澳门| 邳州市| 吐鲁番市| 商南县| 峨眉山市|