【BAT面試寶典】螞蟻金服面試題之分佈式全局ID的常見的實現方案有哪些？

爲什麼要用分佈式全局ID背景

拿MySQL數據庫舉個栗子：

在我們業務數據量不大的時候，單庫單表完全可以支撐現有業務，數據再大一點搞個MySQL主從同步讀寫分離也能對付。

但隨着數據日漸增長，主從同步也扛不住了，就需要對數據庫進行分庫分表，但分庫分表後需要有一個唯一ID來標識一條數據，數據庫的自增ID顯然不能滿足需求；特別一點的如訂單、優惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一ID的系統是非常必要的。那麼這個全局唯一ID就叫分佈式ID。

在互聯網的業務系統中，涉及到各種各樣的ID，如在支付系統中就會有支付ID、退款ID等。
那一般生成ID都有哪些解決方案呢？特別是在複雜的分佈式系統業務場景中，我們應該採用哪種適合自己的解決方案是十分重要的。下面我們一一來列舉一下，不一定全部適合，這些解決方案僅供你參考，或許對你有用。其實有很多實現方式，先來看看一張圖：

假如我們需要滿足以下分佈式ID的特性

唯一性：確保生成的ID是全網唯一的。
有序遞增性：確保生成的ID是對於某個用戶或者業務是按一定的數字有序遞增的。
高可用性：確保任何時候都能正確的生成ID。
帶時間：ID裏面包含時間，一眼掃過去就知道哪天的交易。

方案一：數據庫自增ID

使用數據庫的id自增策略，如 MySQL 的 auto_increment。並且可以使用兩臺數據庫分別設置不同步長，生成不重複ID的策略來實現高可用。

set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2;  -- 步長

優點：

（1）簡單，使用數據庫已有的功能
（2）能夠保證唯一性
（3）數據庫生成的id能夠保證遞增性
（4）步長固定

缺點：

（1）可用性難以保證：數據庫常見架構是一主多從+讀寫分離，生成自增ID是寫請求，主庫掛了就玩不轉了
（2）擴展性差，性能有上限：因爲寫入是單點，數據庫主庫的寫性能決定ID的生成性能上限，並且難以擴展

改進方法：

（1）增加主庫，避免寫入單點
（2）數據水平切分，保證各主庫生成的ID不重複

如上圖所述，由1個寫庫變成3個寫庫，每個寫庫設置不同的auto_increment初始值，以及相同的增長步長，以保證每個數據庫生成的ID是不同的（上圖中庫0生成0,3,6,9…，庫1生成1,4,7,10，庫2生成2,5,8,11…）

改進後的架構保證了可用性，但缺點是：

（1）喪失了ID生成的“絕對遞增性”：先訪問庫0生成0,3，再訪問庫1生成1，可能導致在非常短的時間內，ID生成不是絕對遞增的（這個問題不大，我們的目標是趨勢遞增，不是絕對遞增）
（2）數據庫的寫壓力依然很大，每次生成ID都要訪問數據庫
爲了解決上述兩個問題，引出了下面的常見的方案

進一步改進爲批量生成ID（號段模式）

一次按需批量生成多個ID，每次生成都需要訪問數據庫，將數據庫修改爲最大的ID值，並在內存中記錄當前值及最大值。
分佈式系統之所以難，很重要的原因之一是“沒有一個全局時鐘，難以保證絕對的時序”，要想保證絕對的時序，還是隻能使用單點服務，用本地時鐘保證“絕對時序”。數據庫寫壓力大，是因爲每次生成ID都訪問了數據庫，可以使用批量的方式降低數據庫寫壓力。

如上圖所述，數據庫使用雙master保證可用性，數據庫中只存儲當前ID的最大值，例如0。ID生成服務假設每次批量拉取6個ID，服務訪問數據庫，將當前ID的最大值修改爲5，這樣應用訪問ID生成服務索要ID，ID生成服務不需要每次訪問數據庫，就能依次派發0,1,2,3,4,5這些ID了，當ID發完後，再將ID的最大值修改爲11，就能再次派發6,7,8,9,10,11這些ID了，於是數據庫的壓力就降低到原來的1/6了。

優點：

（1）保證了ID生成的絕對遞增有序
（2）大大的降低了數據庫的壓力，ID生成可以做到每秒生成幾萬幾十萬個

缺點：

（1）服務仍然是單點
（2）如果服務掛了，服務重啓起來之後，繼續生成ID可能會不連續，中間出現空洞（服務內存是保存着0,1,2,3,4,5，數據庫中max-id是5，分配到3時，服務重啓了，下次會從6開始分配，4和5就成了空洞，不過這個問題也不大）
（3）雖然每秒可以生成幾萬幾十萬個ID，但畢竟還是有性能上限，無法進行水平擴展

改進方法：

單點服務的常用高可用優化方案是“備用服務”，也叫“影子服務”，所以我們能用以下方法優化上述缺點（1）：

如上圖，對外提供的服務是主服務，有一個影子服務時刻處於備用狀態，當主服務掛了的時候影子服務頂上。這個切換的過程對調用方是透明的，可以自動完成，常用的技術是vip+keepalived，具體就不在這裏展開。

方案二：UUID

算法的核心思想是結合機器的網卡、當地時間、一個隨記數來生成UUID。
UUID爲本地生成ID的方法，即高性能，又時延低。uuid是一種常見的方案：string ID =GenUUID();

public static void main(String[] args) { 
       String uuid = UUID.randomUUID().toString().replaceAll("-","");
       System.out.println(uuid);
 }

優點：

（1）本地生成ID，不需要進行遠程調用，時延低，沒有高可用風險
（2）擴展性好，基本可以認爲沒有性能上限

缺點：

（1）無法保證趨勢遞增
（2）uuid長度過長16 字節128位，36位長度的字符串存儲以及查詢對MySQL的性能消耗較大，MySQL官方明確建議主鍵要儘量越短越好，作爲數據庫主鍵 UUID 的無序性會導致數據位置頻繁變動，嚴重影響性能。常見優化方案爲“轉化爲兩個uint64整數存儲”或者“折半存儲”（注意折半後不能保證唯一性）
（3）沒有具體的業務含義

上面無法保證趨勢遞增 可以增加時間毫秒數

uuid是一個本地算法，生成性能高，但無法保證趨勢遞增，且作爲字符串ID檢索效率低，有沒有一種能保證遞增的本地算法呢？
取當前毫秒數是一種常見方案：uint64 ID = GenTimeMS();

優點：

（1）本地生成ID，不需要進行遠程調用，時延低
（2）生成的ID趨勢遞增
（3）生成的ID是整數，建立索引後查詢效率高

缺點：

（1）如果併發量超過1000，會生成重複的ID，不能保證ID的唯一性。當然，使用微秒可以降低衝突概率，但每秒最多隻能生成1000000個ID，再多的話就一定會衝突了，所以使用微秒並不從根本上解決問題。

方案三：redis 實現

Redis的所有命令操作都是單線程的，本身提供像 incr 或 increby 這樣的自增原子命令，所以能保證生成的 ID 肯定是唯一有序的。

127.0.0.1:6379> set seq_id 1     // 初始化自增ID爲1
OK
127.0.0.1:6379> incr seq_id      // 增加1，並返回遞增後的數值
(integer) 2

優點：

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

缺點：

如果系統中沒有Redis，還需要引入新的組件，增加系統複雜度；需要編碼和配置的工作量比較大。

考慮到單節點的性能瓶頸，可以使用 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

隨便負載到哪個機確定好，未來很難做修改。步長和初始值一定需要事先確定。使用 Redis 集羣也可以解決單點故障的問題。

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

注意：用redis實現需要注意一點，要考慮到redis持久化的問題。redis有兩種持久化方式 RDB 和 AOF

• RDB 會定時打一個快照進行持久化，假如連續自增但redis沒及時持久化，而這會Redis掛掉了，重啓Redis後會出現ID重複的情況。
• AOF 會對每條寫命令進行持久化，即使Redis掛掉了也不會出現ID重複的情況，但由於incr命令的特殊性，會導致Redis重啓恢復的數據時間過長。

方案四：基於雪花算法（Snowflake）模式

snowflake是twitter開源的分佈式ID生成算法，其核心思想是：一個long型的ID，使用其中41bit作爲毫秒數，10bit作爲機器編號，12bit作爲毫秒內序列號。這個算法單機每秒內理論上最多可以生成1000*(2^12)，也就是400W的ID，完全能滿足業務的需求。

借鑑snowflake的思想，結合各公司的業務邏輯和併發量，可以實現自己的分佈式ID生成算法。

舉例，假設某公司ID生成器服務的需求如下：

（1）單機高峯併發量小於1W，預計未來5年單機高峯併發量小於10W

（2）有2個機房，預計未來5年機房數量小於4個

（3）每個機房機器數小於100臺

（4）目前有5個業務線有ID生成需求，預計未來業務線數量小於10個

（5）…

分析過程如下：

（1）高位取從2016年1月1日到現在的毫秒數（假設系統ID生成器服務在這個時間之後上線），假設系統至少運行10年，那至少需要10年365天24小時3600秒1000毫秒=320*10^9，差不多預留39bit給毫秒數

（2）每秒的單機高峯併發量小於10W，即平均每毫秒的單機高峯併發量小於100，差不多預留7bit給每毫秒內序列號

（3）5年內機房數小於4個，預留2bit給機房標識

（4）每個機房小於100臺機器，預留7bit給每個機房內的服務器標識

（5）業務線小於10個，預留4bit給業務線標識

/**
 * Twitter的SnowFlake算法,使用SnowFlake算法生成一個整數，然後轉化爲62進制變成一個短地址URL
 *
 * https://github.com/beyondfengyu/SnowFlake
 */
public class SnowFlakeShortUrl {

    /**
     * 起始的時間戳
     */
    private final static long START_TIMESTAMP = 1480166465631L;

    /**
     * 每一部分佔用的位數
     */
    private final static long SEQUENCE_BIT = 12;   //序列號佔用的位數
    private final static long MACHINE_BIT = 5;     //機器標識佔用的位數
    private final static long DATA_CENTER_BIT = 5; //數據中心佔用的位數

    /**
     * 每一部分的最大值
     */
    private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
    private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;

    private long dataCenterId;  //數據中心
    private long machineId;     //機器標識
    private long sequence = 0L; //序列號
    private long lastTimeStamp = -1L;  //上一次時間戳

    private long getNextMill() {
        long mill = getNewTimeStamp();
        while (mill <= lastTimeStamp) {
            mill = getNewTimeStamp();
        }
        return mill;
    }

    private long getNewTimeStamp() {
        return System.currentTimeMillis();
    }

    /**
     * 根據指定的數據中心ID和機器標誌ID生成指定的序列號
     *
     * @param dataCenterId 數據中心ID
     * @param machineId    機器標誌ID
     */
    public SnowFlakeShortUrl(long dataCenterId, long machineId) {
        if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {
            throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");
        }
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {
            throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");
        }
        this.dataCenterId = dataCenterId;
        this.machineId = machineId;
    }

    /**
     * 產生下一個ID
     *
     * @return
     */
    public synchronized long nextId() {
        long currTimeStamp = getNewTimeStamp();
        if (currTimeStamp < lastTimeStamp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }

        if (currTimeStamp == lastTimeStamp) {
            //相同毫秒內，序列號自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列數已經達到最大
            if (sequence == 0L) {
                currTimeStamp = getNextMill();
            }
        } else {
            //不同毫秒內，序列號置爲0
            sequence = 0L;
        }

        lastTimeStamp = currTimeStamp;

        return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //時間戳部分
                | dataCenterId << DATA_CENTER_LEFT       //數據中心部分
                | machineId << MACHINE_LEFT             //機器標識部分
                | sequence;                             //序列號部分
    }
    
    public static void main(String[] args) {
        SnowFlakeShortUrl snowFlake = new SnowFlakeShortUrl(2, 3);

        for (int i = 0; i < (1 << 4); i++) {
            //10進制
            System.out.println(snowFlake.nextId());
        }
    }
}

優點

這樣設計的64bit標識，可以保證：
（1）每個業務線、每個機房、每個機器生成的ID都是不同的
（2）同一個機器，每個毫秒內生成的ID都是不同的
（3）同一個機器，同一個毫秒內，以序列號區區分保證生成的ID是不同的
（4）將毫秒數放在最高位，保證生成的ID是趨勢遞增的

缺點：

（1）由於“沒有一個全局時鐘”，每臺服務器分配的ID是絕對遞增的，但從全局看，生成的ID只是趨勢遞增的（有些服務器的時間早，有些服務器的時間晚）

（2）生成的ID，例如message-id/ order-id/ tiezi-id，在數據量大時往往需要分庫分表，這些ID經常作爲取模分庫分表的依據，爲了分庫分表後數據均勻，ID生成往往有“取模隨機性”的需求，所以我們通常把每秒內的序列號放在ID的最末位，保證生成的ID是隨機的。

又如果，我們在跨毫秒時，序列號總是歸0，會使得序列號爲0的ID比較多，導致生成的ID取模後不均勻。解決方法是，序列號不是每次都歸0，而是歸一個0到9的隨機數，這個地方。

方案五：百度（uid-generator）

uid-generator是由百度技術部開發，項目GitHub地址 https://github.com/baidu/uid-generator
uid-generator是基於Snowflake算法實現的，與原始的snowflake算法不同在於，uid-generator支持自定義時間戳、工作機器ID和 序列號 等各部分的位數，而且uid-generator中採用用戶自定義workId的生成策略。

uid-generator需要與數據庫配合使用，需要新增一個WORKER_NODE表。當應用啓動時會向數據庫表中去插入一條數據，插入成功後返回的自增ID就是該機器的workId數據由host，port組成。

對於uid-generator ID組成結構：
workId，佔用了22個bit位，時間佔用了28個bit位，序列化佔用了13個bit位，需要注意的是，和原始的snowflake不太一樣，時間的單位是秒，而不是毫秒，workId也不一樣，而且同一應用每次重啓就會消費一個workId。

方案六：美團Leaf

Leaf 是美團開源的分佈式ID生成器，能保證全局唯一性、趨勢遞增、單調遞增、信息安全，裏面也提到了幾種分佈式方案的對比，但也需要依賴關係數據庫、Zookeeper等中間件。

Leaf 最早期需求是各個業務線的訂單ID生成需求。在美團早期，有的業務直接通過DB自增的方式生成ID，有的業務通過redis緩存來生成ID，也有的業務直接用UUID這種方式來生成ID。以上的方式各自有各自的問題，因此我們決定實現一套分佈式ID生成服務來滿足需求。具體Leaf 設計文檔見： leaf 美團分佈式ID生成服務 github地址：https://github.com/Meituan-Dianping/Leaf

目前Leaf覆蓋了美團點評公司內部金融、餐飲、外賣、酒店旅遊、貓眼電影等衆多業務線。在4C8G VM基礎上，通過公司RPC方式調用，QPS壓測結果近5w/s，TP999 1ms。

方案七：滴滴（Tinyid）

Tinyid是用Java開發的一款分佈式id生成系統，基於數據庫號段算法實現，關於這個算法可以參考美團leaf或者tinyid原理介紹。Tinyid擴展了leaf-segment算法，支持了多db(master)，同時提供了java-client(sdk)使id生成本地化，獲得了更好的性能與可用性。Tinyid在滴滴客服部門使用，均通過tinyid-client方式接入，每天生成億級別的id。

tinyid的原理

• tinyid是基於數據庫發號算法實現的，簡單來說是數據庫中保存了可用的id號段，tinyid會將可用號段加載到內存中，之後生成id會直接內存中產生。
• 可用號段在第一次獲取id時加載，如當前號段使用達到一定量時，會異步加載下一可用號段，保證內存中始終有可用號段。
• (如可用號段1～1000被加載到內存，則獲取id時，會從1開始遞增獲取，當使用到一定百分比時，如20%(默認)，即200時，會異步加載下一可用號段到內存，假設新加載的號段是1001～2000,則此時內存中可用號段爲200～1000,1001~2000)，當id遞增到1000時，當前號段使用完畢，下一號段會替換爲當前號段。依次類推。

性能與可用性

性能

1. http方式訪問，性能取決於http server的能力，網絡傳輸速度
2. java-client方式，id爲本地生成，號段長度(step)越長，qps越大，如果將號段設置足夠大，則qps可達1000w+

可用性

1. 依賴db，當db不可用時，因爲server有緩存，所以還可以使用一段時間，如果配置了多個db，則只要有1個db存活，則服務可用
2. 使用tiny-client，只要server有一臺存活，則理論上可用，server全掛，因爲client有緩存，也可以繼續使用一段時間

Tinyid的特性

• 全局唯一的long型id
• 趨勢遞增的id，即不保證下一個id一定比上一個大
• 非連續性
• 提供http和java client方式接入
• 支持批量獲取id
• 支持生成1,3,5,7,9…序列的id
• 支持多個db的配置，無單點

適用場景:只關心id是數字，趨勢遞增的系統，可以容忍id不連續，有浪費的場景
不適用場景:類似訂單id的業務(因爲生成的id大部分是連續的，容易被掃庫、或者測算出訂單量)

依賴

JDK1.7+,maven,mysql, java client目前僅依賴jdk

推薦使用方式

• tinyid-server推薦部署到多個機房的多臺機器

  • 多機房部署可用性更高，http方式訪問需使用方考慮延遲問題

• 推薦使用tinyid-client來獲取id，好處如下:

  • id爲本地生成(調用AtomicLong.addAndGet方法)，性能大大增加
  • client對server訪問變的低頻，減輕了server的壓力
  • 因爲低頻，即便client使用方和server不在一個機房，也無須擔心延遲
  • 即便所有server掛掉，因爲client預加載了號段，依然可以繼續使用一段時間 注:使用tinyid-client方式，如果client機器較多頻繁重啓，可能會浪費較多的id，這時可以考慮使用http方式

• 推薦db配置兩個或更多:

  • db配置多個時，只要有1個db存活，則服務可用 多db配置，如配置了兩個db，則每次新增業務需在兩個db中都寫入相關數據

小結

這篇文章和大家分享了全局id生成服務的幾種常用方案，同時對比了各自的優缺點和適用場景。在實際工作中，大家可以結合自身業務和系統架構體系進行合理選型。