分佈式惟一ID實現

ID生成的核心需求

• 全局惟一

• 趨勢有序

---

爲何要全局惟一

避免ID衝突

著名的例子就是身份證號碼，身份證號碼確實是對人惟一的，然而一我的是能夠辦理多個身份證的，例如你身份證丟了，又從新補辦了一張，號碼不變。

問題來了，由於系統是按照身份證號碼作惟一主鍵的。此時，若是身份證是被盜的狀況下，你是沒有辦法在系統裏面註銷的，由於新舊2個身份證的「主鍵」都是身份證號碼。

也就是說，舊的身份證仍然逍遙在外，徹底有效。這個時候，還好有一個身份證有效時間的東西，只有靠身份證有效期來辨識了。不過，這就是如今這麼多銀行，電信詐騙的由來，撿到一張身份證，去不少銀行，手機，酒店均可以使用！身份證缺少註銷機制！

因此，經驗告訴咱們。不要相信本身的直覺，業務上所謂的惟一每每都是不靠譜的，經不起時間的考研的。因此須要單獨設置一個和業務無關的主鍵，專業術語叫作代理主鍵（surrogate key）。

---

爲何要趨勢有序

提升讀寫性能

以mysql爲例，InnoDB引擎表是基於B+樹的索引組織表(IOT)；每一個表都須要有一個彙集索引(clustered index)；全部的行記錄都存儲在B+樹的葉子節點(leaf pages of the tree)；基於彙集索引的增、刪、改、查的效率相對是最高的；以下圖：

• 若是咱們定義了主鍵(PRIMARY KEY)，那麼InnoDB會選擇其做爲彙集索引；

• 若是沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引；

• 若是也沒有這樣的惟一索引，則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。

綜上總結，若是InnoDB表的數據寫入順序能和B+樹索引的葉子節點順序一致的話，這時候存取效率是最高的，也就是下面這幾種狀況的存取效率最高

• 使用自增列(INT/BIGINT類型)作主鍵，這時候寫入順序是自增的，和B+數葉子節點分裂順序一致；

• 該表不指定自增列作主鍵，同時也沒有能夠被選爲主鍵的惟一索引(上面的條件)，這時候InnoDB會選擇內置的ROWID做爲主鍵，寫入順序和ROWID增加順序一致；

• 除此之外，若是一個InnoDB表又沒有顯示主鍵，又有能夠被選擇爲主鍵的惟一索引，但該惟一索引可能不是遞增關係時(例如字符串、UUID、多字段聯合惟一索引的狀況)，該表的存取效率就會比較差）

---

面對分佈式ID需求，常見的處理方案

1.數據庫自增加序列或字段

利用數據庫自增加，全局數據庫惟一。

優勢：

• 簡單，代碼方便

缺點：

• 兼容性低：不一樣的數據庫語法和實現不一樣，數據庫多版本支持的時候須要做調整。
• 存在單點故障風險：在單個數據庫或讀寫分離或一主多從的狀況下，只有一個主庫能夠生成。
• 擴展性低：性能達不到要求，難以擴展。
• 多個數據庫合併或者涉及到遷移操做難度大。
• 分庫分表麻煩。

2.UUID

利用數據庫或者程序生成，全球惟一。

優勢：

• 簡單，代碼方便。
• 生成ID性能好，基本不會有性能問題。
• 數據遷移，數據合併，數據庫變動。均可以簡單進行。

缺點：

• 不能保證趨勢遞增。
• UUID通常採用字符串存儲，查詢效率低。
• 存儲空間大。
• 傳輸數據量大。
• 不可讀。

3.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進行累加。

優勢：

• 不依賴於數據庫，靈活方便，且性能優於數據庫。
• 數據中ID自然排序，對分頁或者須要排序的結果頗有幫助。

缺點：

• 若是系統中沒有Redis，還須要引進新的組件，增長系統複雜度。
• 須要編碼和配置的工做量比較多。

4.Twitter

twitter在把存儲系統從MySQL遷移到Cassandra的過程當中因爲Cassandra沒有順序ID生成機制，因而本身開發了一套全局惟一ID生成服務：Snowflake。
1 41位的時間序列（精確到毫秒，41位的長度可使用69年）
2 10位的機器標識（10位的長度最多支持部署1024個節點） 
3 12位的計數順序號（12位的計數順序號支持每一個節點每毫秒產生4096個ID序號） 最高位是符號位，始終爲0。
優勢：

• 高性能，低延遲；獨立的應用。
• 按時間有序。 

缺點：

• 須要獨立的開發和部署。
• 強依賴時鐘,若是主機時間回撥,則會形成重複ID,會產生。
• ID雖然有序,可是不連續。

原理：

5.MongoDB的ObjectId

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

ObjectId使用12字節的存儲空間，其生成方式以下：

|0|1|2|3|4|5|6 |7|8|9|10|11|

|時間戳 |機器ID|PID|計數器 |

前四個字節時間戳是從標準紀元開始的時間戳，單位爲秒，有以下特性：

 1 時間戳與後邊5個字節一塊，保證秒級別的惟一性；
 2 保證插入順序大體按時間排序；
 3 隱含了文檔建立時間；
 4 時間戳的實際值並不重要，不須要對服務器之間的時間進行同步（由於加上機器ID和進程ID已保證此值惟一，惟一性是ObjectId的最終訴求）。

機器ID是服務器主機標識，一般是機器主機名的散列值。

同一臺機器上能夠運行多個mongod實例，所以也須要加入進程標識符PID。

前9個字節保證了同一秒鐘不一樣機器不一樣進程產生的ObjectId的惟一性。後三個字節是一個自動增長的計數器（一個mongod進程須要一個全局的計數器），保證同一秒的ObjectId是惟一的。同一秒鐘最多容許每一個進程擁有（256^3 = 16777216）個不一樣的ObjectId。

總結一下：時間戳保證秒級惟一，機器ID保證設計時考慮分佈式，避免時鐘同步，PID保證同一臺服務器運行多個mongod實例時的惟一性，最後的計數器保證同一秒內的惟一性（選用幾個字節既要考慮存儲的經濟性，也要考慮併發性能的上限）。

"_id"既能夠在服務器端生成也能夠在客戶端生成，在客戶端生成能夠下降服務器端的壓力。

6.類snowflake算法

國內有不少廠家基於snowflake算法進行了國產化，例如

百度的uid-generator：

https://github.com/baidu/uid-generator

美團Leaf：

https://github.com/zhuzhong/idleaf

基本是對snowflake的進一步優化，好比解決時鐘 回撥問題！

---

總結

分佈式ID知足條件：

1. 高可用：不能有單點故障。
2. 全局惟一性：不能出現重複的ID。
3. 趨勢遞增：在MySQL InnoDB引擎中使用的是彙集索引，因爲多數RDBMS使用B-tree的數據結構來存儲索引數據，在主鍵的選擇上面咱們應該儘可能使用有序的主鍵保證寫入性能。
4. 時間有序：少一個索引，冷熱數據容易分離。
5. 分片支持：能夠控制ShardingId。好比某一個用戶的文章要放在同一個分片內，這樣查詢效率高，修改也容易。
6. 單調遞增：保證下一個ID必定大於上一個ID，例如事務版本號、IM增量消息、排序等特殊需求。
7. 長度適中：不要太長，最好64bit。使用long比較好操做。
8. 信息安全：若是ID是連續的，惡意用戶的扒取工做就很是容易作了，直接按照順序下載指定URL便可；若是是訂單號就更危險了，競爭對手能夠直接知道咱們一天的單量。因此在一些應用場景下，會須要ID無規則、不規則。

本文參考：https://mp.weixin.qq.com/s/cgCElpjlKcJIE-d3d7JfjQ