分佈式ID生成方案彙總

---

一、目標

1.一、全局惟一

不能出現重複的ID,全局惟一是最基本的要求。

1.二、趨勢有序

業務上分頁查詢需求，排序需求，若是ID直接有序，則沒必要創建更多的索引，增長查詢條件。
並且Mysql InnoDB存儲引擎主鍵使用匯集索引，主鍵有序則寫入性能更高。

1.三、高可用

ID是一條數據的惟一標識，若是ID生成失敗，則影響很大，業務執行不下去。因此好的ID方案須要有高可用。

1.四、信息安全

ID雖然趨勢有序，可是不能夠被看出規則，省得被爬取信息。
瞭解到一個有意思的事情：基於MAC地址生成UUID的算法形成的MAC地址泄露，這個漏洞曾被用於尋找梅麗莎病毒的製做者位置。

二、常見方案介紹

2.一、UUID

UUID(Universally Unique Identifier)是最簡單的生成方案了：

UUID.randomUUID().toString()

生成形如：e811b49b-9ac1-47dc-8ab9-98fa7dd861d0的8-4-4-4-12的字符串。

優勢

• 簡單
• 性能好
• 全球惟一

缺點

• 無序
• 不能標識出此ID的含義，不可讀。
• 字符串太長且無序，做爲MySQL主鍵，影響性能。

2.二、snowflake方案

snowflake是twitter開源的分佈式ID生成算法，核心思想是：一個Long類型的ID,其中41bit做爲毫秒數，10bit做爲機器碼，12bit做爲毫秒內序列號。

優勢

• 毫秒數在高位，自增序列在低位，ID趨勢遞增。
• 以服務方式部署，能夠作高可用。
• 根據業務分配bit位，靈活。

缺點

• 每臺機器的時鐘不一樣，當時鍾回撥可能會發生重複ID。
• 當數據量大時，須要對ID取模分庫分表，在跨毫秒時，序列號老是歸0，會發生取模後分布不均衡。

2.三、基於數據庫Flickr方案

這個方案的思路時採用了MySQL自增加ID的機制（auto_increment+auto_increment_offset）。

經過使用如下SQL獲取不一樣的ID:

begin;
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;

在分佈式系統中，多部署幾臺Mysql，每臺機器的初始值不一樣，步數與機器數量相等。
假設部署N臺機器，步數爲N,每臺機器初始值依次爲：0、一、2...N-1，架構以下：

優勢

• 簡單，利用現有數據庫架構。
• ID自增

缺點

• 依賴DB，配置主從複製能夠增長可用性，可是當主從切換時可能會致使ID重複。
• 水平擴展困難，由於步數與機器數相同。
• 每次獲取ID都須要讀寫數據庫。

2.四、基於Redis生成

基於redis的lua也能夠作Flickr方案，生成的ID爲64位：

• 41bit存放時間（毫秒）
• 12bit存放邏輯分片ID
• 10bit存放自增加ID.

最終ID：((second * 1000 + microSecond / 1000) << (12 + 10)) + (shardId << 10) + seq;

也能夠直接使用INCR或者HINCRBY來作ID生成方案，由於Redis的單線程原子性，性能也很不錯。

優勢

• ID遞增
• 性能好

缺點

• 須要依賴Redis。
• 須要考慮Reids宕機等問題。

三、開源產品

3.一、百度uid-generator

uid-generator是基於Twitter開源的snowflake算法實現，須要依賴Mysql。
Github: baidu/uid-generator
具體文檔參考Github。

3.二、美團Leaf

Leaf——美團點評分佈式ID生成系統
Github: Meituan-Dianping/Leaf

支持號段模式與snowflake模式。

3.三、小米chronos

Github: XiaoMi/chronos
Chronos依賴ZooKeeper，ChronosServer運行時會啓動一個Thrift服務器。

參考

【分佈式全局ID】細聊分佈式ID生成方法
ID生成器，Twitter的雪花算法（Java）
Leaf——美團點評分佈式ID生成系統
萬億級調用系統：微信序列號生成器架構設計及演變
使用Redis實現高併發分佈式序列號生成服務
分佈式ID方案有哪些以及各自的優劣勢，咱們當如何選擇
分佈式ID生成器解決方案
分佈式全局序列ID方案之Redis優化方案
分佈式惟一ID極簡教程