日期：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生成三种方式
- 基于利用MAC地址（若由于某种原因包括隐私考虑, MAC地址不可用或强烈不推荐, 采用以下两种替代方法）
- 基于伪随机数
- 基于加密哈希(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
感谢您的大驾光临, 无论您是习惯右手, 还是左手点赞都木有关系, 如果本文对您有那么丁点儿帮助, 请用您最销魂的姿势点个赞. 如有问题请留言!
