分佈式全局惟一ID生成策略

爲何分佈式系統須要用到ID生成系統

在複雜分佈式系統中，每每須要對大量的數據和消息進行惟一標識。如在美團點評的金融、支付、餐飲、酒店、貓眼電影等產品的系統中，數據日漸增加，對數據庫的分庫分表後須要有一個惟一ID來標識一條數據或消息，數據庫的自增ID顯然不能知足需求；特別一點的如訂單、騎手、優惠券也都須要有惟一ID作標識。此時一個可以生成全局惟一ID的系統是很是必要的。

歸納下來，業務系統對ID號的要求有哪些呢？

ID生成系統的需求

1.全局惟一性：不能出現重複的ID，最基本的要求。
2.趨勢遞增：MySQL InnoDB引擎使用的是彙集索引，因爲多數RDBMS使用B-tree的數據結構來存儲索引數據，在主鍵的選擇上面咱們應儘可能使用有序的主鍵保證寫入性能。
3.單調遞增：保證下一個ID必定大於上一個ID。
4.信息安全：若是ID是連續遞增的，惡意用戶就能夠很容易的窺見訂單號的規則，從而猜出下一個訂單號，若是是競爭對手，就能夠直接知道咱們一天的訂單量。因此在某些場景下，須要ID無規則。

第三、4兩個需求是互斥的，沒法同時知足。

同時，在大型分佈式網站架構中，除了須要知足ID生成自身的需求外，還須要ID生成系統可用性極高。想象如下，若是ID生成系統癱瘓，那麼整個業務沒法進行下去，那將是一次災難。
所以，總結ID生成系統還須要知足以下的需求：
1.高可用，可用性達到5個9或4個9。
2.高QPS，性能不能太差，不然容易形成線程堵塞。
3.平均延遲和TP999(保證99.9%的請求都能成功的最低延遲)延遲都要儘量低。

ID生成系統的類型

UUID

UUID是指在一臺機器在同一時間中生成的數字在全部機器中都是惟一的。按照開放軟件基金會(OSF)制定的標準計算，用到了以太網卡地址、納秒級時間、芯片ID碼和許多可能的數字
UUID由如下幾部分的組合：
（1）當前日期和時間。
（2）時鐘序列。
（3）全局惟一的IEEE機器識別號，若是有網卡，從網卡MAC地址得到，沒有網卡以其餘方式得到。
標準的UUID格式爲：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，以連字號分爲五段形式的36個字符，示例：550e8400-e29b-41d4-a716-446655440000
Java標準類庫中已經提供了UUID的API。

UUID.randomUUID() 

優勢

• 性能很是高：本地生成，沒有網絡消耗。

缺點

• 不易存儲：UUID太長，16字節128位，一般以36長度的字符串表示，不少場景不適用。
• 信息不安全：基於MAC地址生成UUID的算法可能會形成MAC地址泄露，這個漏洞曾被用於尋找梅麗莎病毒的製做者位置。
• ID做爲主鍵時在特定的環境會存在一些問題，好比作DB主鍵的場景下，UUID就很是不適用。

SnowFlake雪花算法

雪花ID生成的是一個64位的二進制正整數，而後轉換成10進制的數。64位二進制數由以下部分組成：

 

snowflake id生成規則

• 1位標識符：始終是0，因爲long基本類型在Java中是帶符號的，最高位是符號位，正數是0，負數是1，因此id通常是正數，最高位是0。
• 41位時間戳：41位時間截不是存儲當前時間的時間截，而是存儲時間截的差值（當前時間截 - 開始時間截 )獲得的值，這裏的的開始時間截，通常是咱們的id生成器開始使用的時間，由咱們程序來指定的。
• 10位機器標識碼：能夠部署在1024個節點，若是機器分機房（IDC）部署，這10位能夠由 5位機房ID + 5位機器ID 組成。
• 12位序列：毫秒內的計數，12位的計數順序號支持每一個節點每毫秒(同一機器，同一時間截)產生4096個ID序號

優勢

• 簡單高效，生成速度快。
• 時間戳在高位，自增序列在低位，整個ID是趨勢遞增的，按照時間有序遞增。
• 靈活度高，能夠根據業務需求，調整bit位的劃分，知足不一樣的需求。

缺點

• 依賴機器的時鐘，若是服務器時鐘回撥，會致使重複ID生成。
• 在分佈式環境上，每一個服務器的時鐘不可能徹底同步，有時會出現不是全局遞增的狀況。

snowflake Java實現

/** * Twitter_Snowflake<br> * SnowFlake的結構以下(每部分用-分開):<br> * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br> * 1位標識，因爲long基本類型在Java中是帶符號的，最高位是符號位，正數是0，負數是1，因此id通常是正數，最高位是0<br> * 41位時間截(毫秒級)，注意，41位時間截不是存儲當前時間的時間截，而是存儲時間截的差值（當前時間截 - 開始時間截) * 獲得的值），這裏的的開始時間截，通常是咱們的id生成器開始使用的時間，由咱們程序來指定的（以下下面程序IdWorker類的startTime屬性）。 * 41位的時間截，可使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br> * 10位的數據機器位，能夠部署在1024個節點，包括5位datacenterId和5位workerId<br> * 12位序列，毫秒內的計數，12位的計數順序號支持每一個節點每毫秒(同一機器，同一時間截)產生4096個ID序號<br> * 加起來恰好64位，爲一個Long型。<br> * SnowFlake的優勢是，總體上按照時間自增排序，而且整個分佈式系統內不會產生ID碰撞(由數據中心ID和機器ID做區分)，而且效率較高， * 經測試，SnowFlake每秒可以產生26萬ID左右。 */ public class SnowflakeIdWorker { // ==============================Fields=========================================== /** 開始時間截 (2015-01-01) */ private final long twepoch = 1420041600000L; /** 機器id所佔的位數 */ private final long workerIdBits = 5L; /** 數據標識id所佔的位數 */ private final long datacenterIdBits = 5L; /** 支持的最大機器id，結果是31 (這個移位算法能夠很快的計算出幾位二進制數所能表示的最大十進制數) */ private final long maxWorkerId = -1L ^ (-1L << workerIdBits); /** 支持的最大數據標識id，結果是31 */ private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); /** 序列在id中佔的位數 */ private final long sequenceBits = 12L; /** 機器ID向左移12位 */ private final long workerIdShift = sequenceBits; /** 數據標識id向左移17位(12+5) */ private final long datacenterIdShift = sequenceBits + workerIdBits; /** 時間截向左移22位(5+5+12) */ private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; /** 生成序列的掩碼，這裏爲4095 (0b111111111111=0xfff=4095) */ private final long sequenceMask = -1L ^ (-1L << sequenceBits); /** 工做機器ID(0~31) */ private long workerId; /** 數據中心ID(0~31) */ private long datacenterId; /** 毫秒內序列(0~4095) */ private long sequence = 0L; /** 上次生成ID的時間截 */ private long lastTimestamp = -1L; //==============================Constructors===================================== /** * 構造函數 * @param workerId 工做ID (0~31) * @param datacenterId 數據中心ID (0~31) */ public SnowflakeIdWorker(long workerId, long datacenterId) { if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId)); } if (datacenterId > maxDatacenterId || datacenterId < 0) { throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId)); } this.workerId = workerId; this.datacenterId = datacenterId; } // ==============================Methods========================================== /** * 得到下一個ID (該方法是線程安全的) * @return SnowflakeId */ public synchronized long nextId() { long timestamp = timeGen(); //若是當前時間小於上一次ID生成的時間戳，說明系統時鐘回退過這個時候應當拋出異常 if (timestamp < lastTimestamp) { throw new RuntimeException( String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp)); } //若是是同一時間生成的，則進行毫秒內序列 if (lastTimestamp == timestamp) { sequence = (sequence + 1) & sequenceMask; //毫秒內序列溢出 if (sequence == 0) { //阻塞到下一個毫秒,得到新的時間戳 timestamp = tilNextMillis(lastTimestamp); } } //時間戳改變，毫秒內序列重置 else { sequence = 0L; } //上次生成ID的時間截 lastTimestamp = timestamp; //移位並經過或運算拼到一塊兒組成64位的ID return ((timestamp - twepoch) << timestampLeftShift) // | (datacenterId << datacenterIdShift) // | (workerId << workerIdShift) // | sequence; } /** * 阻塞到下一個毫秒，直到得到新的時間戳 * @param lastTimestamp 上次生成ID的時間截 * @return 當前時間戳 */ protected long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; } /** * 返回以毫秒爲單位的當前時間 * @return 當前時間(毫秒) */ protected long timeGen() { return System.currentTimeMillis(); } //==============================Test============================================= /** 測試 */ public static void main(String[] args) { SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0); for (int i = 0; i < 1000; i++) { long id = idWorker.nextId(); System.out.println(Long.toBinaryString(id)); System.out.println(id); } } } 

數據庫自增ID機制

主要思路是採用數據庫自增ID + replace_into實現惟一ID的獲取。

create table t_global_id( id bigint(20) unsigned not null auto_increment, stub char(1) not null default '', primary key (id), unique key stub (stub) ) engine=MyISAM; 

# 每次業務可使用如下SQL讀寫MySQL獲得ID號
replace into t_golbal_id(stub) values('a'); select last_insert_id(); 

replace into跟insert功能相似，不一樣點在於：replace into首先嚐試插入數據列表中，若是發現表中已經有此行數據（根據主鍵或惟一索引判斷）則先刪除，再插入。不然直接插入新數據。
固然爲了不數據庫的單點故障，最少須要兩個數據庫實例，經過區分auto_increment的起始值和步長來生成奇偶數的ID。以下：

Server1：
auto-increment-increment = 2
auto-increment-offset = 1

Server2：
auto-increment-increment = 2
auto-increment-offset = 2

優勢

• 簡單。充分藉助數據庫的自增ID機制，可靠性高，生成有序的ID。

缺點

• ID生成依賴數據庫單機的讀寫性能。
• 依賴數據庫，當數據庫異常時整個系統不可用。

對於MySQL的性能問題，能夠用以下方案解決
在分佈式環境中，咱們能夠部署N臺數據庫實例，每臺設置成不一樣的初始值，自增步長爲機器的臺數。每臺的初始值分別爲1,2,3...N，步長爲N。

 

MySQL數據庫自增ID多機圖

以上方案雖然解決了性能問題，可是也存在很大的侷限性：

• 系統水平擴容困難：系統定義好步長以後，增長機器以後調整步長困難。若是要添加機器怎麼辦？假設如今只有一臺機器發號是1,2,3,4,5（步長是1），這個時候須要擴容機器一臺。能夠這樣作：把第二臺機器的初始值設置得比第一臺超過不少，好比14（假設在擴容時間以內第一臺不可能發到14），同時設置步長爲2，那麼這臺機器下發的號碼都是14之後的偶數。而後摘掉第一臺，把ID值保留爲奇數，好比7，而後修改第一臺的步長爲2。讓它符合咱們定義的號段標準，對於這個例子來講就是讓第一臺之後只能產生奇數。擴容方案看起來複雜嗎？貌似還好，如今想象一下若是咱們線上有100臺機器，這個時候要擴容該怎麼作？簡直是噩夢。
• 數據庫壓力大：每次獲取一個ID都必須讀寫一次數據庫。固然對於這種問題，也有相應的解決方案，就是每次獲取ID時都批量獲取一個區間的號段到內存中，用完以後再來獲取。數據庫的性能提升了幾個量級。

第三方軟件生成（Redis）

Redis實現了一個原子操做INCR和INCRBY實現遞增的操做。當使用數據庫性能不夠時，能夠採用Redis來代替，同時使用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

優勢

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

缺點：

• 若是系統中沒有Redis，還須要引入新的組件，增長系統複雜度。
• 須要編碼和配置的工做量比較大。這個都不是最大的問題。

關於分佈式全局惟一ID的生成，各個互聯網公司有不少實現方案，好比美團點評的Leaf-snowflake，用zookeeper解決了各個服務器時鐘回撥的問題，弱依賴zookeeper。以及Leaf-segment相似上面數據庫批量ID獲取的方案。

做者：Misout連接：https://www.jianshu.com/p/9d7ebe37215e來源：簡書