2. 程式人生 > >分散式全域性唯一ID生成策略

分散式全域性唯一ID生成策略

阿新 • • 發佈：2018-11-11

為什麼分散式系統需要用到ID生成系統

在複雜分散式系統中，往往需要對大量的資料和訊息進行唯一標識。如在美團點評的金融、支付、餐飲、酒店、貓眼電影等產品的系統中，資料日漸增長，對資料庫的分庫分表後需要有一個唯一ID來標識一條資料或訊息，資料庫的自增ID顯然不能滿足需求；特別一點的如訂單、騎手、優惠券也都需要有唯一ID做標識。此時一個能夠生成全域性唯一ID的系統是非常必要的。

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

ID生成系統的需求

1.全域性唯一性：不能出現重複的ID，最基本的要求。
2.趨勢遞增：MySQL InnoDB引擎使用的是聚集索引，由於多數RDBMS使用B-tree的資料結構來儲存索引資料，在主鍵的選擇上面我們應儘量使用有序的主鍵保證寫入效能。
3.單調遞增：保證下一個ID一定大於上一個ID。
4.資訊保安：如果ID是連續遞增的，惡意使用者就可以很容易的窺見訂單號的規則，從而猜出下一個訂單號，如果是競爭對手，就可以直接知道我們一天的訂單量。所以在某些場景下，需要ID無規則。

第3、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位二進位制數由如下部分組成：
在這裡插入圖片描述

  • 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。
在這裡插入圖片描述

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

系統水平擴容困難：

系統定義好步長之後，增加機器之後調整步長困難。如果要新增機器怎麼辦？假設現在只有一臺機器發號是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獲取的方案。

參考

Twitter的分散式自增ID演算法snowflake (Java版)
Leaf——美團點評分散式ID生成系統

作者：Misout
連結：https://www.jianshu.com/p/9d7ebe37215e

相關推薦

分散式全域性唯一ID生成策略

為什麼分散式系統需要用到ID生成系統 在複雜分散式系統中，往往需要對大量的資料和訊息進行唯一標識。如在美團點評的金融、支付、餐飲、酒店、貓眼電影等產品的系統中，資料日漸增長，對資料庫的分庫分表後需要有一個唯一ID來標識一條資料或訊息，資料庫的自增ID顯然不能滿足需求；特別一點的如訂單、騎

常見分散式全域性唯一ID生成策略及演算法的對比

全域性唯一的 ID 幾乎是所有系統都會遇到的剛需。這個 id 在搜尋, 儲存資料, 加快檢索速度 等等很多方面都有著重要的意義。工業上有多種策略來獲取這個全域性唯一的id，針對常見的幾種場景，我在這裡進行簡單的總結和對比。 簡單分析一下需求 [1] 所謂全域性唯一的

分散式全域性唯一ID生成策略​

一、背景 分散式系統中我們會對一些資料量大的業務進行分拆，如：使用者表，訂單表。因為資料量巨大一張表無法承接，就會對其進行分庫分表。 但一旦涉及到分庫分表，就會引申出分散式系統中唯一主鍵ID的生成問題。 1.1 唯一ID的特性 整個系統ID唯一; ID是數字型別，而且是趨勢遞增; ID簡短，查詢效率快。

常見分布式全局唯一ID生成策略

keepal 需要 還需 一致性 ons bsp 原子操作 單機 物理 全局唯一的 ID 幾乎是所有系統都會遇到的剛需。這個 id 在搜索, 存儲數據, 加快檢索速度 等等很多方面都有著重要的意義。工業上有多種策略來獲取這個全局唯一的id，針對常見的幾種場景，我在這裏進行簡

分散式全域性唯一ID--SnowFlake演算法

    說到全域性唯一ID，之前做的一個專案，有遇到類似的需求，會有多併發，但是，又需要類似於id的這麼個存在。當時是直接採用的UUID（這個方案實施起來效率最高），當時為了趕進度，就匆匆忙忙的上線了。現在正好來總結一下。    一般情況，實現全域性唯一

分散式系統唯一ID生成方案彙總

系統唯一ID是我們在設計一個系統的時候常常會遇見的問題，也常常為這個問題而糾結。生成ID的方法有很多，適應不同的場景、需求以及效能要求。所以有些比較複雜的系統會有多個ID生成的策略。下面就介紹一些常見的ID生成策略。 1. 資料庫自增長序列或欄位 最常見的方式。利用資

全域性唯一ID生成方案對比 • cenalulu's Tech Blog

彙總了各大公司的全域性唯一ID生成方案，並做了一個簡單的優劣比較 背景：在實現大型分散式程式時，通常會有全域性唯一ID（也成GUID）生成的需求，用來對每一個物件標識一個代號。本文就列舉了博主收集的各種全域性唯一ID生成的方案，做一個簡單的類比和備忘。 GUID的基本需求 一

讀書筆記-zookeeper全域性唯一id生成

public class ZKLock { //提前建立好鎖物件的結點"/lock" CreateMode.PERSISTENT public static final String LOCK_ZNODE = "/lock"; //分散式鎖實現分散式seq生成 public static cl

分散式-全域性唯一id

系統唯一ID是我們在設計一個系統的時候常常會遇見的問題，也常常為這個問題而糾結。 生成ID的方法有很多，適應不同的場景、需求以及效能要求。所以有些比較複雜的系統會有多個ID生成的策略。 一、常見的ID生成策略。 1.1 資料庫自增長序列或欄

分散式全域性唯一ID的實現

分散式全域性唯一ID的實現 前言 上週末考完試，這周正好把工作整理整理，然後也把之前的一些素材，整理一番，也當自己再學習一番。 一方面正好最近看到幾篇這方面的文章，另一方面也是正好工作上有所涉及，所以決定寫一篇這樣的文章。 先是簡單介紹概念和現有解決方案，然後是我對這些方案的總結，最後是我自己專案的解決思路。

go分散式生成全域性唯一ID

因為snowFlake目的是解決分散式下生成唯一id 所以ID中是包含叢集和節點編號在內的 const ( numberBits uint8 = 12 // 表示每個叢集下的每個節點，1毫秒內可生成的id序號的二進位制位 對應上圖中的最後一段 workerBits uint8 = 10

如何在高併發分散式系統中生成全域性唯一Id

又一個多月沒冒泡了，其實最近學了些東西，但是沒有安排時間整理成博文，後續再奉上。最近還寫了一個發郵件的元件以及效能測試請看 《NET開發郵件傳送功能的全面教程(含郵件元件原始碼)》 ，還弄了個MSSQL引數化語法生成器，會在9月整理出來，有興趣的園友可以關注下我的部落格。 分享原由，最近公司用到，並

高併發分散式環境中獲取全域性唯一ID[分散式資料庫全域性唯一主鍵生成]

需求說明 在過去單機系統中，生成唯一ID比較簡單，可以使用mysql的自增主鍵或者oracle中的sequence, 在現在的大型高併發分散式系統中，以上策略就會有問題了，因為不同的資料庫會部署到不同的機器上，一般都是多主例項，而且再加上高併發的話，就會有重複

分散式環境下全域性唯一ID的生成方案

方案1：UUID 優點：能夠非常簡便地保證分散式環境中的唯一性； 缺點： 長度過長，包含32個字元和4個短線； 沒有業務含義，不便於問題排查； 原理： 機器標識（MAC地址、IP地址）+系統

分散式系統應用中生成全域性唯一ID的演算法（snowflake)----java 實現，單例模式

概述 在分散式系統中，有很多的地方需要生成全域性id的場景，比方說，訂單模組，使用者id等。這種情況下大多數的做法是通過UUID來做處理。首先，UUID是36位的一個字串，相對來說是比較長的，一般我們採用的資料庫會是MySQL，因為大多數的情況下，我們都希望我們的資料是可以

分散式儲存中，生成全域性唯一ID的幾種方案

1.自定義生成規則 eg: 3位伺服器編碼+15位年月日時分秒毫秒+3位表編碼+4位隨機碼 （這樣就完全單機完成編碼任務）---共25位 3位伺服器編碼+15位年月日時分秒毫秒+3位表編碼+4流水碼 （這樣流水碼就需要結合資料庫和快

可實現的全域性唯一有序ID生成策略

在部落格園搜素全域性唯一有序ID，羅列出來的文章大致講述了以下幾個問題，常見的生成全域性唯一id的常見方法 ：使用資料庫自動增長序列實現 ； 使用UUID實現；  使用redis實現； 使用Twitter的snowflake演算法實現；使用資料庫+本地快取實現

分散式全域性唯一訂單號生成系統-REDIS-日訂單億級

一、系統準備 1、單redis按照每秒50k的併發支援計算每日可處理數量為40億，高低峰折扣下來10億差不多。 2、最終支援的數量按時按單業務每秒最大訂單數來算 3、如果單redis無法支撐，那麼按業務分配redis即可（業務字首HASH分節點或者直接按業務分節點） 二、程式碼結構

Spring Boot教你一種方法生成全域性唯一ID

一、概述 流水號生成器（全域性唯一 ID生成器）是服務化系統的基礎設施，其在保障系統的正確執行和高可用方面發揮著重要作用。而關於流水號生成演算法首屈一指的當屬 Snowflake雪花演算法，然而 Snowflake本身很難在現實專案中直接使用，因此實際應用時需要一種可落地的方案。 UidGe

分散式ID生成策略(1)_snowflake演算法

轉載： 最近在研究分散式ID的生成方法，發現Twitter的snowflake演算法挺有意思，因此親自動手用Java進行了實現。 snowflake演算法的原理就是用64位整數來表示主鍵，其結構如下圖： 1 bit符號位：設計者不喜歡負數主鍵？方便使用負數標識不正確