最經常使用的分佈式ID解決方案,你知道幾個

1、分佈式ID概念

提及ID,特性就是惟一,在人的世界裏,ID就是身份證,是每一個人的惟一的身份標識。在複雜的分佈式系統中,每每也須要對大量的數據和消息進行惟一標識。舉個例子,數據庫的ID字段在單體的狀況下可使用自增來做爲ID,可是對數據分庫分表後必定須要一個惟一的ID來標識一條數據,這個ID就是分佈式ID。對於分佈式ID而言,也須要具有分佈式系統的特色:高併發,高可用,高性能等特色。git

2、分佈式ID實現方案

下表爲一些經常使用方案對比:github

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

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

號段模式依賴於數據庫,可是區別於數據庫主鍵自增的模式。假設100爲一個號段100,200,300,每取一次能夠得到100個ID,性能顯著提升。docker

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

符號位爲0,0表示正數,ID爲正數。緩存

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

工做機器id位用來存放機器的id,一般分爲5個區域位+5個服務器標識位。架構

序號位是自增。併發

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

根據這個算法的邏輯,只須要將這個算法用Java語言實現出來,封裝爲一個工具方法,那麼各個業務應用能夠直接使用該工具方法來獲取分佈式ID,只需保證每一個業務應用有本身的工做機器id便可,而不須要單獨去搭建一個獲取分佈式ID的應用。下面是推特版的Snowflake算法:less

public class SnowFlake {

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

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

    /**
     * 每一部分的最大值
     */
    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;  //數據中心
    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;
    }

    /**
     * 產生下一個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) {
            //相同毫秒內,序列號自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列數已經達到最大
            if (sequence == 0L) {
                currStmp = getNextMill();
            }
        } else {
            //不一樣毫秒內,序列號置爲0
            sequence = 0L;
        }

        lastStmp = currStmp;

        return (currStmp - START_STMP) << TIMESTMP_LEFT //時間戳部分
                | datacenterId << DATACENTER_LEFT       //數據中心部分
                | 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());
        }

    }
}

3、分佈式ID開源組件

3.1 如何選擇開源組件

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

其次須要看目前的技術能力,根據目前本身或者團隊的技術棧和技術能力,可否能夠平滑的使用。

第三,要看開源組件的社區,主要關注更新是否頻繁、項目是否有人維護、遇到坑的時候能夠取得聯繫尋求幫助、是否在業內被普遍使用等。

3.2 美團Leaf

Leaf是美團基礎研發平臺推出的一個分佈式ID生成服務,名字取自德國哲學家、數學家萊布尼茨的一句話:「There are no two identical leaves in the world.」Leaf具有高可靠、低延遲、全局惟一等特色。目前已經普遍應用於美團金融、美團外賣、美團酒旅等多個部門。具體的技術細節,可參考美團技術博客的一篇文章:《Leaf美團分佈式ID生成服務》。目前,Leaf項目已經在Github上開源:https://github.com/Meituan-Dianping/Leaf。Leaf在特性以下:

  1. 全局惟一,絕對不會出現重複的ID,且ID總體趨勢遞增。
  2. 高可用,服務徹底基於分佈式架構,即便MySQL宕機,也能容忍一段時間的數據庫不可用。
  3. 高併發低延時,在CentOS 4C8G的虛擬機上,遠程調用QPS可達5W+,TP99在1ms內。
  4. 接入簡單,直接經過公司RPC服務或者HTTP調用便可接入。

3.3 百度UidGenerator

UidGenerator百度開源的一款基於Snowflake算法的分佈式高性能惟一ID生成器。採用官網的一段描述:UidGenerator以組件形式工做在應用項目中, 支持自定義workerId位數和初始化策略, 從而適用於docker等虛擬化環境下實例自動重啓、漂移等場景。 在實現上, UidGenerator經過借用將來時間來解決sequence自然存在的併發限制; 採用RingBuffer來緩存已生成的UID, 並行化UID的生產和消費, 同時對CacheLine補齊,避免了由RingBuffer帶來的硬件級「僞共享」問題. 最終單機QPS可達600萬。UidGenerator的GitHub地址:https://github.com/baidu/uid-generator

3.4 開源組件對比

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

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

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

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

相關文章
相關標籤/搜索