什么是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進制表示，大小寫無關。
Universally Unique IDentifier(UUID)，有着正兒八經的RFC規范，是一個128bit的數字，也可以表現為32個16進制的字符，中間用”-”分割。
- 時間戳＋UUID版本號，分三段占16個字符(60bit+4bit)，
- Clock Sequence號與保留字段，占4個字符(13bit＋3bit)，
- 節點標識占12個字符(48bit)，
GUID（Globally Unique Identifier）是UUID的別名；但在實際應用中，GUID通常是指微軟實現的UUID。
UUID的版本
UUID具有多個版本，每個版本的算法不同，應用范圍也不同。
首先是一個特例－－Nil UUID－－通常我們不會用到它，它是由全為0的數字組成，如下：
00000000-0000-0000-0000-000000000000
UUID Version 1：基於時間的UUID
因為時間戳有滿滿的60bit，所以可以盡情花，以100納秒為1，從1582年10月15日算起(能撐3655年，真是位數多給燒的，1582年有意思么)
節點標識也有48bit，一般用MAC地址表達，如果有多塊網卡就隨便用一塊。如果沒網卡，就用隨機數湊數，或者拿一堆盡量多的其他的信息，比如主機名什么的，拼在一起再hash一把。
順序號這16bit則僅用於避免前面的節點標示改變（如網卡改了），時鍾系統出問題（如重啟后時鍾快了慢了），讓它隨機一下避免重復。
但好像Version 1就沒考慮過一台機器上起了兩個進程這類的問題，也沒考慮相同時間戳的並發問題，所以嚴格的Version1沒人實現，接着往下看各個變種吧。
Version1變種 – Hibernate
Hibernate的CustomVersionOneStrategy.java，解決了之前version 1的兩個問題
- 時間戳(6bytes, 48bit)：毫秒級別的，從1970年算起，能撐8925年….
- 順序號(2bytes, 16bit, 最大值65535): 沒有時間戳過了一秒要歸零的事，各搞各的，short溢出到了負數就歸0。
- 機器標識(4bytes 32bit): 拿localHost的IP地址，IPV4呢正好4個byte，但如果是IPV6要16個bytes，就只拿前4個byte。
- 進程標識(4bytes 32bit)： 用當前時間戳右移8位再取整數應付，不信兩條線程會同時啟動。
值得留意就是，機器進程和進程標識組成的64bit Long幾乎不變，只變動另一個Long就夠了。
Version1變種 – MongoDB
MongoDB的ObjectId.java
- 時間戳(4 bytes 32bit): 是秒級別的，從1970年算起，能撐136年。
- 自增序列(3bytes 24bit, 最大值一千六百萬)： 是一個從隨機數開始（機智）的Int不斷加一，也沒有時間戳過了一秒要歸零的事，各搞各的。因為只有3bytes，所以一個4bytes的Int還要截一下后3bytes。
- 機器標識(3bytes 24bit): 將所有網卡的Mac地址拼在一起做個HashCode，同樣一個int還要截一下后3bytes。搞不到網卡就用隨機數混過去。
- 進程標識(2bytes 16bits)：從JMX里搞回來到進程號，搞不到就用進程名的hash或者隨機數混過去。
可見，MongoDB的每一個字段設計都比Hibernate的更合理一點，比如時間戳是秒級別的。總長度也降到了12 bytes 96bit，但如果果用64bit長的Long來保存有點不上不下的，只能表達成byte數組或16進制字符串。
另外對Java版的driver在自增序列那里好像有bug。
Twitter的snowflake派號器
snowflake也是一個派號器，基於Thrift的服務，不過不是用redis簡單自增，而是類似UUID version1，
只有一個Long 64bit的長度，所以IdWorker緊巴巴的分配成：
- 時間戳(42bit) 自從2012年以來(比那些從1970年算起的會過日子)的毫秒數，能撐139年。
- 自增序列(12bit，最大值4096), 毫秒之內的自增，過了一毫秒會重新置0。
- DataCenter ID (5 bit, 最大值32），配置值。
- Worker ID ( 5 bit, 最大值32)，配置值，因為是派號器的id，所以一個數據中心里最多32個派號器就夠了，還會在ZK里做下注冊。
可見，因為是派號器，把機器標識和進程標識都省出來了，所以能夠只用一個Long表達。
另外，這種派號器，client每次只能一個ID，不能批量取，所以額外增加的延時是問題。
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使用方法
#生成基於計算機主機ID和當前時間的UUID print(uuid.uuid1()) #基於命名空間和一個字符的MD5加密的UUID print(uuid.uuid3(uuid.NAMESPACE_DNS,'alaji')) #隨機生成一個UUID print(uuid.uuid4()) #基於命名空間和一個字符的SHA-1加密的UUID print(uuid.uuid5(uuid.NAMESPACE_DNS,'alaji')) #需要轉換成str類型，下面說明
結果
98345eb4-da04-11e8-9133-54ab3a0caf8d 171898c7-77dd-3258-99f8-41664402c08a 31d7df8f-cb78-41aa-bd4b-b73db34f9358 a08d35bf-65b8-558f-beea-369294bebbd8
UUID是128位的全局唯一標識符，通常由32字節的字符串表示。它可以保證時間和空間的唯一性，也稱為GUID，全稱為：UUID —— Universally Unique IDentifier，Python 中叫 UUID。
它通過MAC地址、時間戳、命名空間、隨機數、偽隨機數來保證生成ID的唯一性。
UUID主要有五個算法，也就是五種方法來實現。
- uuid1()——基於時間戳。由MAC地址、當前時間戳、隨機數生成。可以保證全球范圍內的唯一性，但MAC的使用同時帶來安全性問題，局域網中可以使用IP來代替MAC。
- uuid2()——基於分布式計算環境DCE（Python中沒有這個函數）。算法與uuid1相同，不同的是把時間戳的前4位置換為POSIX的UID。實際中很少用到該方法。
- uuid3()——基於名字的MD5散列值。通過計算名字和命名空間的MD5散列值得到，保證了同一命名空間中不同名字的唯一性，和不同命名空間的唯一性，但同一命名空間的同一名字生成相同的uuid。
- uuid4()——基於隨機數。由偽隨機數得到，有一定的重復概率，該概率可以計算出來。
- uuid5()——基於名字的SHA-1散列值。算法與uuid3相同，不同的是使用 Secure Hash Algorithm 1 算法。