分佈式ID設計方案

分佈式ID的定義：

1. 全局惟一
2. 有序性
3. 有意義
4. 高可用
5. 緊湊性
6. 序列號的可預測性

方案1：使用數據庫遞增的順序

最多見的方式。利用數據庫，全數據庫惟一。

 優勢：

1）簡單，代碼方便，性能能夠接受。

2）數字ID自然排序，對分頁或者須要排序的結果頗有幫助。

缺點：

1）不一樣數據庫語法和實現不一樣，數據庫遷移的時候或多數據庫版本支持的時候須要處理。

2）在單個數據庫或讀寫分離或一主多從的狀況下，只有一個主庫能夠生成。有單點故障的風險。

3）在性能達不到要求的狀況下，比較難於擴展。

4）若是碰見多個系統須要合併或者涉及到數據遷移會至關痛苦。

5）分表分庫的時候會有麻煩。

優化方案：

1）針對主庫單點，若是有多個Master庫，則每一個Master庫設置的起始數字不同，步長同樣，能夠是Master的個數。好比：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。這樣就能夠有效生成集羣中的惟一ID，也能夠大大下降ID生成數據庫操做的負載。

方案2：使用UUID(Universally Unique Identifier)

常見的方式。能夠利用數據庫也能夠利用程序生成，通常來講全球惟一。

優勢：

1）簡單，代碼方便。

2）生成ID性能很是好，基本不會有性能問題。

3）全球惟一，在碰見數據遷移，系統數據合併，或者數據庫變動等狀況下，能夠從容應對。

缺點：

1）沒有排序，沒法保證趨勢遞增。

2）UUID每每是使用字符串存儲，查詢的效率比較低。

3）存儲空間比較大，若是是海量數據庫，就須要考慮存儲量的問題。

4）傳輸數據量大

5）不可讀。-->生成的id序列比較複雜，不具備可讀性

方案3：UUID的變種

爲了解決UUID不可讀，可使用UUID to Int64的方法。即

/// <summary>
/// 根據GUID獲取惟一數字序列
/// </summary>
public static long GuidToInt64()
{
    byte[] bytes = Guid.NewGuid().ToByteArray();
    return BitConverter.ToInt64(bytes, 0);
}

 2）爲了解決UUID無序的問題，NHibernate在其主鍵生成方式中提供了Comb算法（combined guid/timestamp）。保留GUID的10個字節，用另6個字節表示GUID生成的時間（DateTime）。

/// <summary> 
/// Generate a new <see cref="Guid"/> using the comb algorithm. 
/// </summary> 
private Guid GenerateComb()
{
    byte[] guidArray = Guid.NewGuid().ToByteArray();
 
    DateTime baseDate = new DateTime(1900, 1, 1);
    DateTime now = DateTime.Now;
 
    // Get the days and milliseconds which will be used to build    
    //the byte string    
    TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks);
    TimeSpan msecs = now.TimeOfDay;
 
    // Convert to a byte array        
    // Note that SQL Server is accurate to 1/300th of a    
    // millisecond so we divide by 3.333333    
    byte[] daysArray = BitConverter.GetBytes(days.Days);
    byte[] msecsArray = BitConverter.GetBytes((long)
      (msecs.TotalMilliseconds / 3.333333));
 
    // Reverse the bytes to match SQL Servers ordering    
    Array.Reverse(daysArray);
    Array.Reverse(msecsArray);
 
    // Copy the bytes into the guid    
    Array.Copy(daysArray, daysArray.Length - 2, guidArray,
      guidArray.Length - 6, 2);
    Array.Copy(msecsArray, msecsArray.Length - 4, guidArray,
      guidArray.Length - 4, 4);
 
    return new Guid(guidArray);
}

 方案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

這個，隨便負載到哪一個機肯定好，將來很難作修改。可是3-5臺服務器基本可以知足器上，均可以得到不一樣的ID。可是步長和初始值必定須要事先須要了。使用Redis集羣也能夠方式單點故障的問題。

另外，比較適合使用Redis來生成天天從0開始的流水號。好比訂單號=日期+當日自增加號。能夠天天在Redis中生成一個Key，使用INCR進行累加。

優勢：

1）不依賴於數據庫，靈活方便，且性能優於數據庫。

2）數字ID自然排序，對分頁或者須要排序的結果頗有幫助。

缺點：

1）若是系統中沒有Redis，還須要引入新的組件，增長系統複雜度。

2）須要編碼和配置的工做量比較大。

方案5：基於Twitter的Snowflake實現

snowflake是Twitter開源的分佈式ID生成算法，結果是一個long型的ID。其核心思想是：使用41bit做爲毫秒數，10bit做爲機器的ID（5個bit是數據中心，5個bit的機器ID），12bit做爲毫秒內的流水號（意味着每一個節點在每毫秒能夠產生 4096 個 ID），最後還有一個符號位，永遠是0。

snowflake算法能夠根據自身項目的須要進行必定的修改。好比估算將來的數據中心個數，每一個數據中心的機器數以及統一毫秒能夠能的併發數來調整在算法中所須要的bit數。

優勢：

1）不依賴於數據庫，靈活方便，且性能優於數據庫。

2）ID按照時間在單機上是遞增的。

缺點：

1）在單機上是遞增的，可是因爲涉及到分佈式環境，每臺機器上的時鐘不可能徹底同步，也許有時候也會出現不是全局遞增的狀況。

Snowflake官方版本：https://github.com/twitter-archive/snowflake

java版本：https://github.com/relops/snowflake

方案6：MongoDB 的ObjectId

MongoDB的ObjectId和snowflake算法相似。它設計成輕量型的，不一樣的機器都能用全局惟一的同種方法方便地生成它。MongoDB 從一開始就設計用來做爲分佈式數據庫，處理多個節點是一個核心要求。使其在分片環境中要容易生成得多。

其格式以下：

前4 個字節是從標準紀元開始的時間戳，單位爲秒。時間戳，與隨後的5 個字節組合起來，提供了秒級別的惟一性。因爲時間戳在前，這意味着ObjectId 大體會按照插入的順序排列。這對於某些方面頗有用，如將其做爲索引提升效率。這4 個字節也隱含了文檔建立的時間。絕大多數客戶端類庫都會公開一個方法從ObjectId 獲取這個信息。
接下來的3 字節是所在主機的惟一標識符。一般是機器主機名的散列值。這樣就能夠確保不一樣主機生成不一樣的ObjectId，不產生衝突。
爲了確保在同一臺機器上併發的多個進程產生的ObjectId 是惟一的，接下來的兩字節來自產生ObjectId 的進程標識符（PID）。
前9 字節保證了同一秒鐘不一樣機器不一樣進程產生的ObjectId 是惟一的。後3 字節就是一個自動增長的計數器，確保相同進程同一秒產生的ObjectId 也是不同的。同一秒鐘最多容許每一個進程擁有2563（16 777 216）個不一樣的ObjectId。

方案7:利用zookeeper生成惟一ID

zookeeper主要經過其znode數據版原本生成序列號，能夠生成32位和64位的數據版本號，客戶端可使用這個版本號來做爲惟一的序列號。
不多會使用zookeeper來生成惟一ID。主要是因爲須要依賴zookeeper，而且是多步調用API，若是在競爭較大的狀況下，須要考慮使用分佈式鎖。所以，性能在高併發的分佈式環境下，也不甚理想。

參考連接：https://www.cnblogs.com/haoxinyue/p/5208136.html

https://time.geekbang.org/column/article/12806

方案8：其它方案設計：

百度uid-generator: https://github.com/baidu/uid-generator/  有對比測試記錄

騰訊微信序列號生成器：https://github.com/nebula-im/seqsvr

美團的Leaf-Segment： https://tech.meituan.com/MT_Leaf.html

snowflake 的erlang版本：https://github.com/boundary/flake

時間位數限制的解決方案：時間戳減去常量，對於已經生成的歷史id，能夠導入表刷id

時間數據位數的限制

極客時間版權全部: https://time.geekbang.org/column/article/12806

提供了一個 12 byte（96 位）的 ID 定義，其中 ...

極客時間版權全部: https://time.geekbang.org/column/article/1280

分佈式 ID 定義

極客時間版權全部: https://time.geekbang.org/column/article/12806