系統唯一id是我們在設計乙個系統的時候常常會遇見的問題，也常常為這個問題而糾結。生成id的方法有很多，適應不同的場景、需求以及效能要求。所以有些比較複雜的系統會有多個id生成的策略。下面就介紹一些常見的id生成策略。
1. 資料庫自增長序列或字段
最常見的方式。利用資料庫，全資料庫唯一。auto_increment。
優點：
缺點：
優化方案：
2. uuid
常見的方式。可以利用資料庫也可以利用程式生成，一般來說全球唯一。
優點：
缺點：
3. uuid的變種
1）為了解決uuid不可讀，可以使用uuid to int64的方法。
///
/// 根據guid獲取唯一數字序列
///
public
static
long
guidtoint64()
///
/// generate a new using the comb algorithm.
///
private guid generatecomb()
如果想把時間序放在前面，可以生成後改變12個字串的位置，也可以修改演算法類的最後兩個array.copy。
4. redis生成id（常用）
當使用資料庫來生成id效能不夠要求的時候，我們可以嘗試使用redis來生成id。這主要依賴於redis是單執行緒的，所以也可以用生成全域性唯一的id。可以用redis的原子操作 incr和incrby來實現。
可以使用redis集群來獲取更高的吞吐量。假如乙個集群中有5臺redis。可以初始化每台redis的值分別是1,2,3,4,5，然後步長都是5。各個redis生成的id為：
a：1,6,11,16,21
b：2,7,12,17,22
c：3,8,13,18,23
d：4,9,14,19,24
e：5,10,15,20,25
另外，比較適合使用redis來生成每天從0開始的流水號。比如訂單號=日期+當日自增長號。可以每天在redis中生成乙個key，使用incr進行累加。
優點：
缺點：
5. twitter的snowflake演算法
snowflake是twitter開源的分布式id生成演算法，結果是乙個long型的id。其核心思想是：使用41bit作為毫秒數，10bit作為機器的id（5個bit是資料中心，5個bit的機器id），12bit作為毫秒內的流水號（意味著每個節點在每毫秒可以產生 4096 個 id），最後還有乙個符號位，永遠是0。具體實現的**可以參看
snowflake演算法可以根據自身專案的需要進行一定的修改。比如估算未來的資料中心個數，每個資料中心的機器數以及統一毫秒可以能的併發數來調整在演算法中所需要的bit數。
優點：
缺點：
6. 利用zookeeper生成唯一id
zookeeper主要通過其znode資料版本來生成序列號，可以生成32位和64位的資料版本號，客戶端可以使用這個版本號來作為唯一的序列號。
很少會使用zookeeper來生成唯一id。主要是由於需要依賴zookeeper，並且是多步調用api，如果在競爭較大的情況下，需要考慮使用分布式鎖。因此，效能在高併發的分布式環境下，也不甚理想。
7.總結
以上是幾種常見的分布式系統唯一id的生成策略，採用哪種策略主要還是要根據當前的條件來進行選擇。我的分布式學習之路，繼續衝！2020.3.28
分布式系統唯一ID生成方案彙總
前言 系統唯一id是我們在設計乙個系統的時候常常會遇見的問題，也常常為這個問題而糾結。生成id的方法有很多，適應不同的場景 需求以及效能要求。所以有些比較複雜的系統會有多個id生成的策略。下面就介紹一些常見的id生成策略。一 資料庫自增長序列或字段 最常見的方式。利用資料庫，全資料庫唯一。優點 簡單...
分布式系統唯一ID生成方案彙總
1.資料庫自增長序列或字段 最常見的方式。利用資料庫，全資料庫唯一。優點 1 簡單，方便，效能可以接受。2 數字id天然排序，對分頁或者需要排序的結果很有幫助。缺點 1 不同資料庫語法和實現不同，資料庫遷移的時候或多資料庫版本支援的時候需要處理。2 在單個資料庫或讀寫分離或一主多從的情況下，只有乙個...
分布式唯一ID的生成方案
不能出現重複的id，這是最基本的要求。有利於關聯式資料庫索引效能。既然是服務於分布式系統，為多個服務提供id服務，訪問壓力一定很大，所以需要保證高可用。如果id是有規律的，就容易被惡意操作，在一些場景下需要id無規則。核心思想是結合機器的網絡卡 當地時間 乙個隨機數來生成。優點 缺點 利用資料庫自增...