「一、分布式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類型占用空間較邪仔蕖；2. 主鍵自動增長重斑，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+序列號組成的，如圖所示：

圖片

符號位為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ù)能力康吵，能否可以平滑的使用劈榨。

第三，要看開源組件的社區(qū)晦嵌，主要關(guān)注更新是否頻繁鞋既、項目是否有人維護、遇到坑的時候可以取得聯(lián)系尋求幫助耍铜、是否在業(yè)內(nèi)被廣泛使用等邑闺。

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解決方案呢亡呵？