【經(jīng)驗】分布式 ID 方案對比:UUID/數(shù)據(jù)庫主鍵自增/Redis自增/雪花算法

一、分布式ID概念

說起ID,特性就是唯一,在人的世界里,ID就是身份證,是每個人的唯一的身份標識。在復雜的分布式系統(tǒng)中,往往也需要對大量的數(shù)據(jù)和消息進行唯一標識。舉個例子,數(shù)據(jù)庫的ID字段在單體的情況下可以使用自增來作為ID,但是對數(shù)據(jù)分庫分表后一定需要一個唯一的ID來標識一條數(shù)據(jù),這個ID就是分布式ID。對于分布式ID而言,也需要具備分布式系統(tǒng)的特點:高并發(fā),高可用,高性能等特點。

二、分布式ID實現(xiàn)方案

下表為一些常用方案對比:

描述 優(yōu)點 缺點
UUID UUID是通用唯一標識碼的縮寫,其目的是上分布式系統(tǒng)中的所有元素都有唯一的辨識信息,而不需要通過中央控制器來指定唯一標識。 1. 降低全局節(jié)點的壓力,使得主鍵生成速度更快;2. 生成的主鍵全局唯一;3. 跨服務(wù)器合并數(shù)據(jù)方便 1. UUID占用16個字符,空間占用較多;2. 不是遞增有序的數(shù)字,數(shù)據(jù)寫入IO隨機性很大,且索引效率下降
數(shù)據(jù)庫主鍵自增 MySQL數(shù)據(jù)庫設(shè)置主鍵且主鍵自動增長 1. INT和BIGINT類型占用空間較?。?. 主鍵自動增長,IO寫入連續(xù)性好;3. 數(shù)字類型查詢速度優(yōu)于字符串 1. 并發(fā)性能不高,受限于數(shù)據(jù)庫性能;2. 分庫分表,需要改造,復雜;3. 自增:數(shù)據(jù)量泄露
Redis自增 Redis計數(shù)器,原子性自增 使用內(nèi)存,并發(fā)性能好 1. 數(shù)據(jù)丟失;2. 自增:數(shù)據(jù)量泄露
雪花算法(snowflake) 大名鼎鼎的雪花算法,分布式ID的經(jīng)典解決方案 1. 不依賴外部組件;2. 性能好 時鐘回撥

目前流行的分布式ID解決方案有兩種:號段模式雪花算法

號段模式依賴于數(shù)據(jù)庫,但是區(qū)別于數(shù)據(jù)庫主鍵自增的模式。假設(shè)100為一個號段100,200,300,每取一次可以獲得100個ID,性能顯著提高。

雪花算法是由符號位+時間戳+工作機器id+序列號組成的,如圖所示:

image

符號位為0,0表示正數(shù),ID為正數(shù)。

時間戳位不用多說,用來存放時間戳,單位是ms。

工作機器id位用來存放機器的id,通常分為5個區(qū)域位+5個服務(wù)器標識位。

序號位是自增。

  • 雪花算法能存放多少數(shù)據(jù)?
    時間范圍:2^41 / (3652460601000) = 69年
    工作進程范圍:2^10 = 1024
    序列號范圍:2^12 = 4096,表示1ms可以生成4096個ID。

根據(jù)這個算法的邏輯,只需要將這個算法用Java語言實現(xiàn)出來,封裝為一個工具方法,那么各個業(yè)務(wù)應(yīng)用可以直接使用該工具方法來獲取分布式ID,只需保證每個業(yè)務(wù)應(yīng)用有自己的工作機器id即可,而不需要單獨去搭建一個獲取分布式ID的應(yīng)用。下面是推特版的Snowflake算法:

public class SnowFlake {

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

    /**
     * 每一部分占用的位數(shù)
     */
    private final static long SEQUENCE_BIT = 12; //序列號占用的位數(shù)
    private final static long MACHINE_BIT = 5;   //機器標識占用的位數(shù)
    private final static long DATACENTER_BIT = 5;//數(shù)據(jù)中心占用的位數(shù)

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

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;

    private long datacenterId;  //數(shù)據(jù)中心
    private long machineId;     //機器標識
    private long sequence = 0L; //序列號
    private long lastStmp = -1L;//上一次時間戳

    public SnowFlake(long datacenterId, long machineId) {
        if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {
            throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_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;
    }

    /**
     * 產(chǎn)生下一個ID
     *
     * @return
     */
    public synchronized long nextId() {
        long currStmp = getNewstmp();
        if (currStmp < lastStmp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }

        if (currStmp == lastStmp) {
            //相同毫秒內(nèi),序列號自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列數(shù)已經(jīng)達到最大
            if (sequence == 0L) {
                currStmp = getNextMill();
            }
        } else {
            //不同毫秒內(nèi),序列號置為0
            sequence = 0L;
        }

        lastStmp = currStmp;

        return (currStmp - START_STMP) << TIMESTMP_LEFT //時間戳部分
                | datacenterId << DATACENTER_LEFT       //數(shù)據(jù)中心部分
                | machineId << MACHINE_LEFT             //機器標識部分
                | sequence;                             //序列號部分
    }

    private long getNextMill() {
        long mill = getNewstmp();
        while (mill <= lastStmp) {
            mill = getNewstmp();
        }
        return mill;
    }

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

    public static void main(String[] args) {
        SnowFlake snowFlake = new SnowFlake(2, 3);

        for (int i = 0; i < (1 << 12); i++) {
            System.out.println(snowFlake.nextId());
        }

    }
}

三、分布式ID開源組件

3.1 如何選擇開源組件

選擇開源組件首先需要看軟件特性是否滿足需求,主要包括兼容性和擴展性。

其次需要看目前的技術(shù)能力,根據(jù)目前自己或者團隊的技術(shù)棧和技術(shù)能力,能否可以平滑的使用。假設(shè)一個組件是某語言開發(fā)的,而我對這個語言一無所知,那么就不適合使用,如果強行要用,必然要投入更多的精力,要再三權(quán)衡投入和收益再做選擇。

第三,要看開源組件的社區(qū),主要關(guān)注更新是否頻繁、項目是否有人維護、遇到坑的時候可以取得聯(lián)系尋求幫助、是否在業(yè)內(nèi)被廣泛使用等?;钴S的社區(qū)說明有許多用戶在使用,有句話說有人的地方就有江湖,其實在技術(shù)領(lǐng)域,有人的地方就有技術(shù)的進步,遇到坑就可以相對比較容易得到解決;如果是組件本身的問題,也會相對及時的得到修復。

3.2 美團Leaf

Leaf是美團基礎(chǔ)研發(fā)平臺推出的一個分布式ID生成服務(wù),名字取自德國哲學家、數(shù)學家萊布尼茨的一句話:“There are no two identical leaves in the world.”Leaf具備高可靠、低延遲、全局唯一等特點。目前已經(jīng)廣泛應(yīng)用于美團金融、美團外賣、美團酒旅等多個部門。具體的技術(shù)細節(jié),可參考美團技術(shù)博客的一篇文章:《Leaf美團分布式ID生成服務(wù)》。目前,Leaf項目已經(jīng)在Github上開源:https://github.com/Meituan-Dianping/Leaf。Leaf在特性如下:

  1. 全局唯一,絕對不會出現(xiàn)重復的ID,且ID整體趨勢遞增。
  2. 高可用,服務(wù)完全基于分布式架構(gòu),即使MySQL宕機,也能容忍一段時間的數(shù)據(jù)庫不可用。
  3. 高并發(fā)低延時,在CentOS 4C8G的虛擬機上,遠程調(diào)用QPS可達5W+,TP99在1ms內(nèi)。
  4. 接入簡單,直接通過公司RPC服務(wù)或者HTTP調(diào)用即可接入。

3.3 百度UidGenerator

UidGenerator百度開源的一款基于Snowflake算法的分布式高性能唯一ID生成器。采用官網(wǎng)的一段描述:UidGenerator以組件形式工作在應(yīng)用項目中, 支持自定義workerId位數(shù)和初始化策略, 從而適用于docker等虛擬化環(huán)境下實例自動重啟、漂移等場景。 在實現(xiàn)上, UidGenerator通過借用未來時間來解決sequence天然存在的并發(fā)限制; 采用RingBuffer來緩存已生成的UID, 并行化UID的生產(chǎn)和消費, 同時對CacheLine補齊,避免了由RingBuffer帶來的硬件級「偽共享」問題. 最終單機QPS可達600萬。UidGenerator的GitHub地址:https://github.com/baidu/uid-generator

3.4 開源組件對比

百度UidGenerator是Java語言的;最近一次提交記錄是兩年前,基本無人維護;只支持雪花算法。

美團Leaf也是Java語言的;最近維護為2020年;支持號段模式和雪花算法。

綜上理論和兩款開源組件的對比,還是美團Leaf稍勝一籌。

你還知道哪些常用的分布式ID解決方案呢?

*本文轉(zhuǎn)載自James_Shangguan的《 最常用的分布式ID解決方案,你知道幾個

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,646評論 6 533
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,595評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 176,560評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,035評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,814評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,224評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,301評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,444評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,988評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,804評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,998評論 1 370
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,544評論 5 360
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,237評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,665評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,927評論 1 287
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,706評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,993評論 2 374

推薦閱讀更多精彩內(nèi)容