主鍵生成策略
系統唯一ID是我們在設計一個系統的時候常常會遇見的問題，下面介紹一些常見的ID生成策略。
- Sequence ID
- UUID
- GUID
- COMB
- Snowflake
最開始的自增ID為了實現分庫分別的需求，會在自增的前提下，使用不同步長(例如DB1 生成1,4,7,10，DB2生成2,5,8,11，DB3生成3,6,9,12)，但需要做數據庫拓展時，極其麻煩。
相比自增ID，UUID生成唯一主鍵更加方便（數據量非常大的情況下，存在重復的可能），但由于UUID的無序性，性能不如自增ID，字符串儲存，儲存空間大，查詢效率低。
COMB相對于UUID，增加了生成ID的有序性，插入與查詢效率都有所提高。見Integer GUID和Comb做主鍵的效率測試(Delphi+access)(三)
Sonwflake是Twitter主鍵生成策略，可以看做是COMB的一種改進，用64位的長整型代替128位的字符串。ID構成：第一位0 + 41位的時間前綴 + 10位的節點標識 + 12位的sequence避免并發的數字。見Twitter-Snowflake（64位分布式ID算法）分析與JAVA實現
1. Sequence ID
數據庫自增長序列或字段，最常見的方式。由數據庫維護，數據庫唯一。
優點：
- 簡單，代碼方便，性能可以接受。
- 數字ID天然排序，對分頁或者需要排序的結果很有幫助。
缺點：
- 不同數據庫語法和實現不同，數據庫遷移的時候或多數據庫版本支持的時候需要處理。
- 在單個數據庫或讀寫分離或一主多從的情況下，只有一個主庫可以生成。有單點故障的風險。
- 在性能達不到要求的情況下，比較難于擴展。
- 如果遇見多個系統需要合并或者涉及到數據遷移會相當痛苦。
- 分表分庫的時候會有麻煩。
優化方案：
- 針對主庫單點，如果有多個Master庫，則每個Master庫設置的起始數字不一樣，步長一樣，可以是Master的個數。
比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。這樣就可以有效生成集群中的唯一ID，也可以大大降低ID生成數據庫操作的負載。
2. UUID
常見的方式,128位。可以利用數據庫也可以利用程序生成，一般來說全球唯一。
優點：
- 簡單，代碼方便。
- 全球唯一，在遇見數據遷移，系統數據合并，或者數據庫變更等情況下，可以從容應對。
缺點：
- 沒有排序，無法保證趨勢遞增。
- UUID往往是使用字符串存儲，查詢的效率比較低。
- 存儲空間比較大，如果是海量數據庫，就需要考慮存儲量的問題。
- 傳輸數據量大
- 不可讀。
優化方案：
- 為了解決UUID不可讀，可以使用UUID to Int64的方法。
3. GUID
GUID：是微軟對UUID這個標準的實現。UUID還有其它各種實現，不止GUID一種。優缺點同UUID。
4. COMB
COMB（combine）型是數據庫特有的一種設計思想，可以理解為一種改進的GUID，它通過組合GUID和系統時間，以使其在索引和檢索事有更優的性能。
數據庫中沒有COMB類型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來的。
COMB數據類型的基本設計思路是這樣的：既然UniqueIdentifier數據因毫無規律可言造成索引效率低下，影響了系統的性能，那么我們能不能通過組合的方式，保留UniqueIdentifier的前10個字節，用后6個字節表示GUID生成的時間（DateTime），這樣我們將時間信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。
優點：
- 解決UUID無序的問題，在其主鍵生成方式中提供了Comb算法(combined guid/timestamp)。保留GUID的10個字節，用另6個字節表示GUID生成的時間(DateTime)。
- 性能優于UUID。
5. Twitter的snowflake算法
snowflake是Twitter開源的分布式ID生成算法，結果是一個long型的ID。其核心思想是：使用41bit作為毫秒數，10bit作為機器的ID（5個bit是數據中心，5個bit的機器ID），12bit作為毫秒內的流水號（意味著每個節點在每毫秒可以產生 4096 個 ID），最后還有一個符號位，永遠是0。snowflake算法可以根據自身項目的需要進行一定的修改。比如估算未來的數據中心個數，每個數據中心的機器數以及統一毫秒可以能的并發數來調整在算法中所需要的bit數。
優點：
- 不依賴于數據庫，靈活方便，且性能優于數據庫。
- ID按照時間在單機上是遞增的。
缺點：
- 在單機上是遞增的，但是由于涉及到分布式環境，每臺機器上的時鐘不可能完全同步，也許有時候也會出現不是全局遞增的情況。
參考：
- 分布式系統唯一ID生成方案匯總
- UUID 、GUID、COMB 的區別與聯系
- UUID 和 GUID 的區別
- The Cost of GUIDs as Primary Keys
- Integer GUID和Comb做主鍵的效率測試(Delphi+access)(三)
- Twitter-Snowflake項目地址（Tags:snowflake-2010）
- 如何在高并發分布式系統中生成全局唯一Id
- Twitter-Snowflake（64位分布式ID算法）分析與JAVA實現
轉載注明出處，我就不和你計較。
by Donney Young
http://www.lxweimin.com/p/a0a3aa888a49
