UUID惟一資源命名空間的前因後果(RFC4122)

日期：2014-04-26(該死, 又凌晨了)
原文參考：http://tools.ietf.org/html/rfc4122.html

前言：高級與普通程序員的區別就是, 普通程序只復(cao)用(xie)代碼片斷, 而高級一點的無非就只知道點規範, 寫點東西, 讓其餘人Copy

本屌最討厭的面試題是, XXX爲何這麼設計, TMD我哪知道啊, 創始人就這麼寫, 我也沒轍啊!

簡介

UUID, 又名全球獨立標識(Globally Unique Identifier), 固然原名更高大上點兒, A.K.A 宇宙獨立標識（Universally Unique Identifier). UUID最初用在一個本屌沒聽過的網絡系統中, 而後被普遍應用到微軟抄作系統.

UUID是128位(長度固定)unsigned integer, 可以保證(真的假的？)在空間(Space)與時間(Time)上的惟一性。並且無需註冊機制保證, 能夠按需隨時生成。

據WIKI, 隨機算法生成的UUID的重複機率爲170億分之一

因爲UUID定長且與時間有關, 有必定可能性UUID會重複出現（大概在西元(A.D)3400, 與具體實現算法有關）

UUID生成算法最高支持10,000,000(一千萬)每秒每臺機器, 因此能夠用做交易流水ID

uuid(Python)和NSUUID(iOS)遵循本RFC

UUID生成三種方式

1. 基於利用MAC地址（若因爲某種緣由包括隱私考慮, MAC地址不可用或強烈不推薦, 採用如下兩種替代方法）
2. 基於僞隨機數
3. 基於加密哈希(MD5之類的東東)和應用自定義字符串

字符表示

[time-low]-[time-mide]-[time-high-and-version]-[clock-seq-and-reserved 和 clock-seq-low]-[node]

time-low = 32位 unsigned integer
time-mid = 16位 unsigned integer
time-high-and-version = 16位 unsigned integer(時間戳高位部分與版本(Version)號混合)
clock-seq-and-reserved = 8位 unsigned integer(時鐘序列高位部分與預約義變量(Variant)混合組成)
clock-seq-low = 8位 unsigned integer
node = 48位 unsigned integer

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

字段組成(詳情與事例代碼,參考RFC4122 section4 till the end)

UUID採用Big-endian字節序排列

變量(variant), 或稱作類型, 4 bytes, 包括如下4種（其中X爲任意值）:
0XX NCS兼容預留
10X RFC4122採用
110 微軟兼容預留
111 還未定義, 留做之後它用

版本號(version), 4 bytes, 一共如下5個版本:
0001 時間的版本
0010 DCE Security
0011 MD5哈希
0100 (僞)隨機數
0101 SHA-1哈希

時間戳(timestamp), 60bit:
版本1: 時間戳採用UTC時間,以100ns爲間隔,重1582年10月15日00:00:00.00開始計算

時鐘序列, 14bit:
版本1: 用來防止在時間回調的狀況下,致使的UUID重複問題
若是有時間回調(可能有系統斷電致使),若是生成器在回調時間以後有生成新的UUID,那麼時鐘序列應該改變, 若是新生成的UUID時鐘序列可知,那麼時鐘序列遞增便可; 若不可知, 那麼時鐘序列應重置到一個47位隨機數,或一個47位高質量的僞隨機數,而且第48位設置爲1,用來區別真正的MAC地址(因爲全部MAC地址在網卡中第48爲0)

節點(node), 48bit:
版本1: 爲主機MAC地址, 若主機有多個MAC地址,隨機選其中一個, 若系統沒有MAC地址, 則採用(僞)隨機數.

其餘版本請參考原文, 其中版本2沒有在原文中敘述

Nil UUID

128位中,每一位都是零, (A.K.A)
urn:uuid:00000000-0000-0000-0000-000000000000

感謝您的大駕光臨, 不管您是習慣右手, 仍是左手點贊都木有關係, 若是本文對您有那麼丁點兒幫助, 請用您最銷魂的姿式點個贊. 若有問題請留言!