一個(gè)美女面試官坐到我的對(duì)面，發(fā)光logo的MacBook也擋不住她那圓潤(rùn)可愛的臉龐。

程序媛本就稀有，美女面試官更是難尋。

這么溫柔可愛的面試官，應(yīng)該不會(huì)為難我吧。嗯，應(yīng)該是的，畢竟我這么帥氣，面試可能就是走個(gè)過場(chǎng)。美女面試官是不是單身？畢竟程序員都不善交流，因?yàn)槲乙彩菃紊?，難道我的姻緣就在此注定。孩子的名字我都想好了。一冰！好名字。

面試官： 小伙子，你低著頭笑什么吶。開始面試了，你知道訂單ID是怎么生成的嗎？

啥？訂單ID怎么生成？美女怎么不按套路出牌！HashMap實(shí)現(xiàn)原理，我已經(jīng)倒背如流，你不問。瞎問什么訂單ID。

我： 還能咋生成？用數(shù)據(jù)庫(kù)主鍵自增唄。

面試官： 這樣不行啊。數(shù)據(jù)庫(kù)主鍵順序自增，每天有多少訂單量被競(jìng)爭(zhēng)對(duì)手看的一清二楚，商業(yè)機(jī)密都暴露了。
況且單機(jī)MySQL只能支持幾百量級(jí)的并發(fā)，我們公司每天千萬訂單量，hold不住啊。

我： 嗯，那就用用數(shù)據(jù)庫(kù)集群，自增ID起始值按機(jī)器編號(hào)，步長(zhǎng)等于機(jī)器數(shù)量。
比如有兩臺(tái)機(jī)器，第一臺(tái)機(jī)器生成的ID是1、3、5、7，第二臺(tái)機(jī)器生成的ID是2、4、6、8。性能不行就加機(jī)器，這并發(fā)量der一下就上去了。

面試官： 小伙子，你想得倒是挺好。你有沒有想過實(shí)現(xiàn)百萬級(jí)的并發(fā)，大概就需要2000臺(tái)機(jī)器，你這還只是用來生成訂單ID，公司再有錢也經(jīng)不起這么造。

我： 既然MySQL的并發(fā)量不行，我們是不是可以提前從MySQL獲取一批自增ID，加載到本地內(nèi)存中，然后從內(nèi)存中并發(fā)取，這并發(fā)性能豈不是杠杠滴。

面試官： 你還挺上道，這種叫號(hào)段模式。并發(fā)量是上去了，但是自增ID還是不能作為訂單ID的。

我： 用Java自帶UUID怎么樣？

import java.util.UUID;

/**
 * @author yideng
 * @apiNote UUID示例
 */
public class UUIDTest {
    public static void main(String[] args) {
        String orderId = UUID.randomUUID().toString().replace("-", "");
        System.out.println(orderId);
    }
}

輸出結(jié)果：

58e93ecab9c64295b15f7f4661edcbc1

面試官： 也不行。32位字符串會(huì)占用更大的空間，無序的字符串作數(shù)據(jù)庫(kù)主鍵，每次插入數(shù)據(jù)庫(kù)的時(shí)候，MySQL為了維護(hù)B+樹結(jié)構(gòu)，需要頻繁調(diào)整節(jié)點(diǎn)順序，影響性能。況且字符串太長(zhǎng)，也沒有任何業(yè)務(wù)含義，pass。

小伙子，你可能是沒參與過電商系統(tǒng)，我先跟說一下生成訂單ID要滿足哪些條件：

全局唯一：如果訂單ID重復(fù)了，肯定要完蛋。
高性能：要做到高并發(fā)、低延遲。生成訂單ID都成為瓶頸了，那還得了。
高可用：至少要做到4個(gè)9，別動(dòng)不動(dòng)就宕機(jī)了。
易用性：如果為了滿足上述要求，搞了幾百臺(tái)服務(wù)器，復(fù)雜且難以維護(hù)，也不行。
數(shù)值且有序遞增：數(shù)值占用的空間更小，有序遞增能保證插入MySQL的時(shí)候更高性能。
嵌入業(yè)務(wù)含義：如果訂單ID里面能嵌入業(yè)務(wù)含義，就能通過訂單ID知道是哪個(gè)業(yè)務(wù)線生成的，便于排查問題。

我擦，生成一個(gè)小小的訂單ID，搞出這么多規(guī)則，還能玩下去嗎？難道今天的面試要跪，怎么可能。一燈的文章我一直訂閱，這個(gè)還能難得住我，陪美女程序員玩玩還當(dāng)真了。

我： 我聽說圈內(nèi)有一種流傳已久的分布式、高性能、高可用的訂單ID生成算法—雪花算法，完全能滿足你的上述要求。雪花算法生成ID是Long類型，長(zhǎng)度64位。

第 1 位： 符號(hào)位，暫時(shí)不用。
第 2~42 位： 共41位，時(shí)間戳，單位是毫秒，可以支撐大約69年
第 43~52 位： 共10位，機(jī)器ID，最多可容納1024臺(tái)機(jī)器
第 53~64 位： 共12位，序列號(hào)，是自增值，表示同一毫秒內(nèi)產(chǎn)生的ID，單臺(tái)機(jī)器每毫秒最多可生成4096個(gè)訂單ID

代碼實(shí)現(xiàn)：

/**
 * @author 一燈架構(gòu)
 * @apiNote 雪花算法
 **/
public class SnowFlake {

    /**
     * 起始時(shí)間戳，從2021-12-01開始生成
     */
    private final static long START_STAMP = 1638288000000L;

    /**
     * 序列號(hào)占用的位數(shù) 12
     */
    private final static long SEQUENCE_BIT = 12;

    /**
     * 機(jī)器標(biāo)識(shí)占用的位數(shù)
     */
    private final static long MACHINE_BIT = 10;

    /**
     * 機(jī)器數(shù)量最大值
     */
    private final static long MAX_MACHINE_NUM = ~(-1L << MACHINE_BIT);

    /**
     * 序列號(hào)最大值
     */
    private final static long MAX_SEQUENCE = ~(-1L << SEQUENCE_BIT);

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

    /**
     * 機(jī)器標(biāo)識(shí)
     */
    private long machineId;
    /**
     * 序列號(hào)
     */
    private long sequence = 0L;
    /**
     * 上一次時(shí)間戳
     */
    private long lastStamp = -1L;

    /**
     * 構(gòu)造方法
     * @param machineId 機(jī)器ID
     */
    public SnowFlake(long machineId) {
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {
            throw new RuntimeException("機(jī)器超過最大數(shù)量");
        }
        this.machineId = machineId;
    }

    /**
     * 產(chǎn)生下一個(gè)ID
     */
    public synchronized long nextId() {
        long currStamp = getNewStamp();
        if (currStamp < lastStamp) {
            throw new RuntimeException("時(shí)鐘后移，拒絕生成ID！");
        }

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

        lastStamp = currStamp;

        return (currStamp - START_STAMP) << TIMESTAMP_LEFT // 時(shí)間戳部分
                | machineId << MACHINE_LEFT             // 機(jī)器標(biāo)識(shí)部分
                | sequence;                             // 序列號(hào)部分
    }

    private long getNextMill() {
        long mill = getNewStamp();
        while (mill <= lastStamp) {
            mill = getNewStamp();
        }
        return mill;
    }

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

    public static void main(String[] args) {
        // 訂單ID生成測(cè)試，機(jī)器ID指定第0臺(tái)
        SnowFlake snowFlake = new SnowFlake(0);
        System.out.println(snowFlake.nextId());
    }
}

輸出結(jié)果：

6836348333850624

接入非常簡(jiǎn)單，不需要搭建服務(wù)集群，。代碼邏輯非常簡(jiǎn)單，，同一毫秒內(nèi)，訂單ID的序列號(hào)自增。同步鎖只作用于本機(jī)，機(jī)器之間互不影響，每毫秒可以生成四百萬個(gè)訂單ID，非常強(qiáng)悍。

生成規(guī)則不是固定的，可以根據(jù)自身的業(yè)務(wù)需求調(diào)整。如果你不需要那么大的并發(fā)量，可以把機(jī)器標(biāo)識(shí)位拆出一部分，當(dāng)作業(yè)務(wù)標(biāo)識(shí)位，標(biāo)識(shí)是哪個(gè)業(yè)務(wù)線生成的訂單ID。

面試官： 小伙子，有點(diǎn)東西，深藏不漏啊。再問個(gè)更難的問題，你覺得雪花算法還有改進(jìn)的空間嗎？

你真是打破砂鍋問到底，不把我問趴下不結(jié)束。幸虧來之前我瞥了一眼一燈的文章。

我： 有的，雪花算法嚴(yán)重依賴系統(tǒng)時(shí)鐘。如果時(shí)鐘回?fù)埽蜁?huì)生成重復(fù)ID。

面試官： 有什么解決辦法嗎？

我： 有問題就會(huì)有答案。比如美團(tuán)的Leaf（美團(tuán)自研一種分布式ID生成系統(tǒng)），為了解決時(shí)鐘回?fù)?，引入了zookeeper，原理也很簡(jiǎn)單，就是比較當(dāng)前系統(tǒng)時(shí)間跟生成節(jié)點(diǎn)的時(shí)間。

有的對(duì)并發(fā)要求更高的系統(tǒng)，比如雙十一秒殺，每毫秒4百萬并發(fā)還不能滿足要求，就可以使用雪花算法和號(hào)段模式相結(jié)合，比如百度的UidGenerator、滴滴的TinyId。想想也是，號(hào)段模式的預(yù)先生成ID肯定是高性能分布式訂單ID的最終解決方案。

面試官： 小伙子，我看你簡(jiǎn)歷上寫著已經(jīng)離職了。明天就來上班吧，薪資double，就這樣了。

總結(jié)

到此這篇關(guān)于面試官問訂單ID是如何生成的文章就介紹到這了,更多相關(guān)MySQL自增主鍵生成訂單ID內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論