分布式中的分庫分表之后,ID 主鍵如何處理?


面試題

分庫分表之后,id 主鍵如何處理?(唯一性,排序等)

面試官心理分析

其實這是分庫分表之后你必然要面對的一個問題,就是 id 咋生成?因為要是分成多個表之后,每個表都是從 1 開始累加,那肯定不對啊,需要一個全局唯一的 id 來支持,排序問題等。所以這都是你實際生產環境中必須考慮的問題。

面試題剖析

基於數據庫的實現方案

數據庫自增 id

這個就是說你的系統里每次得到一個 id,都是往一個庫的一個表里插入一條沒什么業務含義的數據,然后獲取一個數據庫自增的一個 id。拿到這個 id 之后再往對應的分庫分表里去寫入。

這個方案的好處就是方便簡單,誰都會用;缺點就是單庫生成自增 id,要是高並發的話,就會有瓶頸的;如果你硬是要改進一下,那么就專門開一個服務出來,這個服務每次就拿到當前 id 最大值,然后自己遞增幾個 id,一次性返回一批 id,然后再把當前最大 id 值修改成遞增幾個 id 之后的一個值;但是無論如何都是基於單個數據庫

適合的場景:你分庫分表就倆原因,要不就是單庫並發太高,要不就是單庫數據量太大;除非是你並發不高,但是數據量太大導致的分庫分表擴容,你可以用這個方案,因為可能每秒最高並發最多就幾百,那么就走單獨的一個庫和表生成自增主鍵即可。

設置數據庫 sequence 或者表自增字段步長

可以通過設置數據庫 sequence 或者表的自增字段步長來進行水平伸縮。

比如說,現在有 8 個服務節點,每個服務節點使用一個 sequence 功能來產生 ID,每個 sequence 的起始 ID 不同,並且依次遞增,步長都是 8。

file

適合的場景:在用戶防止產生的 ID 重復時,這種方案實現起來比較簡單,也能達到性能目標。但是服務節點固定,步長也固定,將來如果還要增加服務節點,就不好搞了。

UUID

好處就是本地生成,不要基於數據庫來了;不好之處就是,UUID 太長了、占用空間大,作為主鍵性能太差了;更重要的是,UUID 不具有有序性,會導致 B+ 樹索引在寫的時候有過多的隨機寫操作(連續的 ID 可以產生部分順序寫),還有,由於在寫的時候不能產生有順序的 append 操作,而需要進行 insert 操作,將會讀取整個 B+ 樹節點到內存,在插入這條記錄后會將整個節點寫回磁盤,這種操作在記錄占用空間比較大的情況下,性能下降明顯。

適合的場景:如果你是要隨機生成個什么文件名、編號之類的,你可以用 UUID,但是作為主鍵是不能用 UUID 的。

UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf

獲取系統當前時間

這個就是獲取當前時間即可,但是問題是,並發很高的時候,比如一秒並發幾千,會有重復的情況,這個是肯定不合適的。基本就不用考慮了。

適合的場景:一般如果用這個方案,是將當前時間跟很多其他的業務字段拼接起來,作為一個 id,如果業務上你覺得可以接受,那么也是可以的。你可以將別的業務字段值跟當前時間拼接起來,組成一個全局唯一的編號。

snowflake 算法

snowflake 算法是 twitter 開源的分布式 id 生成算法,采用 Scala 語言實現,是把一個 64 位的 long 型的 id,1 個 bit 是不用的  +  用其中的 41 bit 作為毫秒數  +  用 10 bit 作為工作機器 id  +  12 bit 作為序列號。

  • 1 bit:不用,為啥呢?因為二進制里第一個 bit 為如果是 1,那么都是負數,但是我們生成的 id 都是正數,所以第一個 bit 統一都是 0。
  • 41 bit:表示的是時間戳,單位是毫秒。41 bit 可以表示的數字多達 2^41 - 1,也就是可以標識 2^41 - 1 個毫秒值,換算成年就是表示69年的時間。
  • 10 bit:記錄工作機器 id,代表的是這個服務最多可以部署在 2^10台機器上哪,也就是1024台機器。但是 10 bit 里 5 個 bit 代表機房 id,5 個 bit 代表機器 id。意思就是最多代表 2^5個機房(32個機房),每個機房里可以代表 2^5 個機器(32台機器)。
  • 12 bit:這個是用來記錄同一個毫秒內產生的不同 id,12 bit 可以代表的最大正整數是 2^12 - 1 = 4096,也就是說可以用這個 12 bit 代表的數字來區分同一個毫秒內的 4096 個不同的 id。
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000
public class IdWorker {

    private long workerId;
    private long datacenterId;
    private long sequence;

    public IdWorker(long workerId, long datacenterId, long sequence) {
        // sanity check for workerId
        // 這兒不就檢查了一下,要求就是你傳遞進來的機房id和機器id不能超過32,不能小於0
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(
                    String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(
                    String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        System.out.printf(
                "worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
                timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);

        this.workerId = workerId;
        this.datacenterId = datacenterId;
        this.sequence = sequence;
    }

    private long twepoch = 1288834974657L;

    private long workerIdBits = 5L;
    private long datacenterIdBits = 5L;

    // 這個是二進制運算,就是 5 bit最多只能有31個數字,也就是說機器id最多只能是32以內
    private long maxWorkerId = -1L ^ (-1L << workerIdBits);

    // 這個是一個意思,就是 5 bit最多只能有31個數字,機房id最多只能是32以內
    private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    private long sequenceBits = 12L;

    private long workerIdShift = sequenceBits;
    private long datacenterIdShift = sequenceBits + workerIdBits;
    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    private long sequenceMask = -1L ^ (-1L << sequenceBits);

    private long lastTimestamp = -1L;

    public long getWorkerId() {
        return workerId;
    }

    public long getDatacenterId() {
        return datacenterId;
    }

    public long getTimestamp() {
        return System.currentTimeMillis();
    }

    public synchronized long nextId() {
        // 這兒就是獲取當前時間戳,單位是毫秒
        long timestamp = timeGen();

        if (timestamp < lastTimestamp) {
            System.err.printf("clock is moving backwards. Rejecting requests until %d.", lastTimestamp);
            throw new RuntimeException(String.format(
                    "Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        if (lastTimestamp == timestamp) {
            // 這個意思是說一個毫秒內最多只能有4096個數字
            // 無論你傳遞多少進來,這個位運算保證始終就是在4096這個范圍內,避免你自己傳遞個sequence超過了4096這個范圍
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0;
        }

        // 這兒記錄一下最近一次生成id的時間戳,單位是毫秒
        lastTimestamp = timestamp;

        // 這兒就是將時間戳左移,放到 41 bit那兒;
        // 將機房 id左移放到 5 bit那兒;
        // 將機器id左移放到5 bit那兒;將序號放最后12 bit;
        // 最后拼接起來成一個 64 bit的二進制數字,轉換成 10 進制就是個 long 型
        return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift)
                | (workerId << workerIdShift) | sequence;
    }

    private long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

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

    // ---------------測試---------------
    public static void main(String[] args) {
        IdWorker worker = new IdWorker(1, 1, 1);
        for (int i = 0; i < 30; i++) {
            System.out.println(worker.nextId());
        }
    }

}

怎么說呢,大概這個意思吧,就是說 41 bit 是當前毫秒單位的一個時間戳,就這意思;然后 5 bit 是你傳遞進來的一個機房 id(但是最大只能是 32 以內),另外 5 bit 是你傳遞進來的機器 id(但是最大只能是 32 以內),剩下的那個 12 bit序列號,就是如果跟你上次生成 id 的時間還在一個毫秒內,那么會把順序給你累加,最多在 4096 個序號以內。

所以你自己利用這個工具類,自己搞一個服務,然后對每個機房的每個機器都初始化這么一個東西,剛開始這個機房的這個機器的序號就是 0。然后每次接收到一個請求,說這個機房的這個機器要生成一個 id,你就找到對應的 Worker 生成。

利用這個 snowflake 算法,你可以開發自己公司的服務,甚至對於機房 id 和機器 id,反正給你預留了 5 bit + 5 bit,你換成別的有業務含義的東西也可以的。

當然,你也可以用 : 1 個 bit 是不用的  +  用其中的 41 bit 作為毫秒數   +  12 bit 作為序列號  +  用 10 bit 作為工作機器 id,或者顛倒兌換一下順序,怎么使用根據你自己的業務需要進行組合配用。

這個 snowflake 算法相對來說還是比較靠譜的,所以你要真是搞分布式 id 生成,如果是高並發啥的,那么用這個應該性能比較好,一般每秒幾萬並發的場景,也足夠你用了。

本文在米兜公眾號鏈接:
https://mp.weixin.qq.com/s/mt8bVpM57SsI-nvTRKxSKg

 

出處:https://www.cnblogs.com/midoujava/p/11610492.html

============================================================================================

如果僅僅是保證唯一性,自己寫一個算法和規則,根據這個規則各個模塊自己生成編號;

比如,之前寫過一個簡單的示例,使用xml文件作為配置生成固定格式的序列號的配置文件,程序根據算法生成指定格式的字符串。類似日期的格式化函數。

但是往往很多時候又需要把多份數據匯總、聚合等,還有排序等情況,這個時候需要根據生成的記錄進行排序(也可考慮根據插入時間排序,各有利弊),還要考慮精度:有時、分、秒、厘秒、毫秒、微妙等等,當多台服務器進行時間同步到時候,還有需要靠網絡延遲等情況。

所有,要根據自己的業務需要和自己能夠承受的容錯率來確定。

============================================================================================

 

本文已經收錄自 JavaGuide (60k+ Star【Java學習+面試指南】 一份涵蓋大部分Java程序員所需要掌握的核心知識。)

本文授權轉載自:https://juejin.im/post/5d6fc8eff265da03ef7a324b ,作者:1點25。

ID是數據的唯一標識,傳統的做法是利用UUID和數據庫的自增ID,在互聯網企業中,大部分公司使用的都是Mysql,並且因為需要事務支持,所以通常會使用Innodb存儲引擎,UUID太長以及無序,所以並不適合在Innodb中來作為主鍵,自增ID比較合適,但是隨着公司的業務發展,數據量將越來越大,需要對數據進行分表,而分表后,每個表中的數據都會按自己的節奏進行自增,很有可能出現ID沖突。這時就需要一個單獨的機制來負責生成唯一ID,生成出來的ID也可以叫做分布式ID,或全局ID。下面來分析各個生成分布式ID的機制。

常用分布式id方案

這篇文章並不會分析的特別詳細,主要是做一些總結,以后再出一些詳細某個方案的文章。

數據庫自增ID

第一種方案仍然還是基於數據庫的自增ID,需要單獨使用一個數據庫實例,在這個實例中新建一個單獨的表:

表結構如下:

CREATE DATABASE `SEQID`;

CREATE TABLE SEQID.SEQUENCE_ID (
    id bigint(20) unsigned NOT NULL auto_increment, 
    stub char(10) NOT NULL default '',
    PRIMARY KEY (id),
    UNIQUE KEY stub (stub)
) ENGINE=MyISAM;

可以使用下面的語句生成並獲取到一個自增ID

begin;
replace into SEQUENCE_ID (stub) VALUES ('anyword');
select last_insert_id();
commit;

stub字段在這里並沒有什么特殊的意義,只是為了方便的去插入數據,只有能插入數據才能產生自增id。而對於插入我們用的是replace,replace會先看是否存在stub指定值一樣的數據,如果存在則先delete再insert,如果不存在則直接insert。

這種生成分布式ID的機制,需要一個單獨的Mysql實例,雖然可行,但是基於性能與可靠性來考慮的話都不夠,業務系統每次需要一個ID時,都需要請求數據庫獲取,性能低,並且如果此數據庫實例下線了,那么將影響所有的業務系統。

為了解決數據庫可靠性問題,我們可以使用第二種分布式ID生成方案。

數據庫多主模式

如果我們兩個數據庫組成一個主從模式集群,正常情況下可以解決數據庫可靠性問題,但是如果主庫掛掉后,數據沒有及時同步到從庫,這個時候會出現ID重復的現象。我們可以使用雙主模式集群,也就是兩個Mysql實例都能單獨的生產自增ID,這樣能夠提高效率,但是如果不經過其他改造的話,這兩個Mysql實例很可能會生成同樣的ID。需要單獨給每個Mysql實例配置不同的起始值和自增步長。

第一台Mysql實例配置:

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

第二台Mysql實例配置:

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

經過上面的配置后,這兩個Mysql實例生成的id序列如下: mysql1,起始值為1,步長為2,ID生成的序列為:1,3,5,7,9,... mysql2,起始值為2,步長為2,ID生成的序列為:2,4,6,8,10,...

對於這種生成分布式ID的方案,需要單獨新增一個生成分布式ID應用,比如DistributIdService,該應用提供一個接口供業務應用獲取ID,業務應用需要一個ID時,通過rpc的方式請求DistributIdService,DistributIdService隨機去上面的兩個Mysql實例中去獲取ID。

實行這種方案后,就算其中某一台Mysql實例下線了,也不會影響DistributIdService,DistributIdService仍然可以利用另外一台Mysql來生成ID。

但是這種方案的擴展性不太好,如果兩台Mysql實例不夠用,需要新增Mysql實例來提高性能時,這時就會比較麻煩。

現在如果要新增一個實例mysql3,要怎么操作呢? 第一,mysql1、mysql2的步長肯定都要修改為3,而且只能是人工去修改,這是需要時間的。 第二,因為mysql1和mysql2是不停在自增的,對於mysql3的起始值我們可能要定得大一點,以給充分的時間去修改mysql1,mysql2的步長。 第三,在修改步長的時候很可能會出現重復ID,要解決這個問題,可能需要停機才行。

為了解決上面的問題,以及能夠進一步提高DistributIdService的性能,如果使用第三種生成分布式ID機制。

號段模式

我們可以使用號段的方式來獲取自增ID,號段可以理解成批量獲取,比如DistributIdService從數據庫獲取ID時,如果能批量獲取多個ID並緩存在本地的話,那樣將大大提供業務應用獲取ID的效率。

比如DistributIdService每次從數據庫獲取ID時,就獲取一個號段,比如(1,1000],這個范圍表示了1000個ID,業務應用在請求DistributIdService提供ID時,DistributIdService只需要在本地從1開始自增並返回即可,而不需要每次都請求數據庫,一直到本地自增到1000時,也就是當前號段已經被用完時,才去數據庫重新獲取下一號段。

所以,我們需要對數據庫表進行改動,如下:

CREATE TABLE id_generator (
  id int(10) NOT NULL,
  current_max_id bigint(20) NOT NULL COMMENT '當前最大id',
  increment_step int(10) NOT NULL COMMENT '號段的長度',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

這個數據庫表用來記錄自增步長以及當前自增ID的最大值(也就是當前已經被申請的號段的最后一個值),因為自增邏輯被移到DistributIdService中去了,所以數據庫不需要這部分邏輯了。

這種方案不再強依賴數據庫,就算數據庫不可用,那么DistributIdService也能繼續支撐一段時間。但是如果DistributIdService重啟,會丟失一段ID,導致ID空洞。

為了提高DistributIdService的高可用,需要做一個集群,業務在請求DistributIdService集群獲取ID時,會隨機的選擇某一個DistributIdService節點進行獲取,對每一個DistributIdService節點來說,數據庫連接的是同一個數據庫,那么可能會產生多個DistributIdService節點同時請求數據庫獲取號段,那么這個時候需要利用樂觀鎖來進行控制,比如在數據庫表中增加一個version字段,在獲取號段時使用如下SQL:

update id_generator set current_max_id=#{newMaxId}, version=version+1 where version = #{version}

因為newMaxId是DistributIdService中根據oldMaxId+步長算出來的,只要上面的update更新成功了就表示號段獲取成功了。

為了提供數據庫層的高可用,需要對數據庫使用多主模式進行部署,對於每個數據庫來說要保證生成的號段不重復,這就需要利用最開始的思路,再在剛剛的數據庫表中增加起始值和步長,比如如果現在是兩台Mysql,那么 mysql1將生成號段(1,1001],自增的時候序列為1,3,4,5,7.... mysql1將生成號段(2,1002],自增的時候序列為2,4,6,8,10...

更詳細的可以參考滴滴開源的TinyId:github.com/didi/tinyid…

在TinyId中還增加了一步來提高效率,在上面的實現中,ID自增的邏輯是在DistributIdService中實現的,而實際上可以把自增的邏輯轉移到業務應用本地,這樣對於業務應用來說只需要獲取號段,每次自增時不再需要請求調用DistributIdService了。

雪花算法

上面的三種方法總的來說是基於自增思想的,而接下來就介紹比較著名的雪花算法-snowflake。

我們可以換個角度來對分布式ID進行思考,只要能讓負責生成分布式ID的每台機器在每毫秒內生成不一樣的ID就行了。

snowflake是twitter開源的分布式ID生成算法,是一種算法,所以它和上面的三種生成分布式ID機制不太一樣,它不依賴數據庫。

核心思想是:分布式ID固定是一個long型的數字,一個long型占8個字節,也就是64個bit,原始snowflake算法中對於bit的分配如下圖:

雪花算法

  • 第一個bit位是標識部分,在java中由於long的最高位是符號位,正數是0,負數是1,一般生成的ID為正數,所以固定為0。
  • 時間戳部分占41bit,這個是毫秒級的時間,一般實現上不會存儲當前的時間戳,而是時間戳的差值(當前時間-固定的開始時間),這樣可以使產生的ID從更小值開始;41位的時間戳可以使用69年,(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
  • 工作機器id占10bit,這里比較靈活,比如,可以使用前5位作為數據中心機房標識,后5位作為單機房機器標識,可以部署1024個節點。
  • 序列號部分占12bit,支持同一毫秒內同一個節點可以生成4096個ID

根據這個算法的邏輯,只需要將這個算法用Java語言實現出來,封裝為一個工具方法,那么各個業務應用可以直接使用該工具方法來獲取分布式ID,只需保證每個業務應用有自己的工作機器id即可,而不需要單獨去搭建一個獲取分布式ID的應用。

snowflake算法實現起來並不難,提供一個github上用java實現的:github.com/beyondfengy…

在大廠里,其實並沒有直接使用snowflake,而是進行了改造,因為snowflake算法中最難實踐的就是工作機器id,原始的snowflake算法需要人工去為每台機器去指定一個機器id,並配置在某個地方從而讓snowflake從此處獲取機器id。

但是在大廠里,機器是很多的,人力成本太大且容易出錯,所以大廠對snowflake進行了改造。

百度(uid-generator)

github地址:uid-generator

uid-generator使用的就是snowflake,只是在生產機器id,也叫做workId時有所不同。

uid-generator中的workId是由uid-generator自動生成的,並且考慮到了應用部署在docker上的情況,在uid-generator中用戶可以自己去定義workId的生成策略,默認提供的策略是:應用啟動時由數據庫分配。說的簡單一點就是:應用在啟動時會往數據庫表(uid-generator需要新增一個WORKER_NODE表)中去插入一條數據,數據插入成功后返回的該數據對應的自增唯一id就是該機器的workId,而數據由host,port組成。

對於uid-generator中的workId,占用了22個bit位,時間占用了28個bit位,序列化占用了13個bit位,需要注意的是,和原始的snowflake不太一樣,時間的單位是秒,而不是毫秒,workId也不一樣,同一個應用每重啟一次就會消費一個workId。

具體可參考github.com/baidu/uid-g…

美團(Leaf)

github地址:Leaf

美團的Leaf也是一個分布式ID生成框架。它非常全面,即支持號段模式,也支持snowflake模式。號段模式這里就不介紹了,和上面的分析類似。

Leaf中的snowflake模式和原始snowflake算法的不同點,也主要在workId的生成,Leaf中workId是基於ZooKeeper的順序Id來生成的,每個應用在使用Leaf-snowflake時,在啟動時都會都在Zookeeper中生成一個順序Id,相當於一台機器對應一個順序節點,也就是一個workId。

總結

總得來說,上面兩種都是自動生成workId,以讓系統更加穩定以及減少人工成功。

Redis

這里額外再介紹一下使用Redis來生成分布式ID,其實和利用Mysql自增ID類似,可以利用Redis中的incr命令來實現原子性的自增與返回,比如:

127.0.0.1:6379> set seq_id 1     // 初始化自增ID為1
OK
127.0.0.1:6379> incr seq_id      // 增加1,並返回
(integer) 2
127.0.0.1:6379> incr seq_id      // 增加1,並返回
(integer) 3

使用redis的效率是非常高的,但是要考慮持久化的問題。Redis支持RDB和AOF兩種持久化的方式。

RDB持久化相當於定時打一個快照進行持久化,如果打完快照后,連續自增了幾次,還沒來得及做下一次快照持久化,這個時候Redis掛掉了,重啟Redis后會出現ID重復。

AOF持久化相當於對每條寫命令進行持久化,如果Redis掛掉了,不會出現ID重復的現象,但是會由於incr命令過得,導致重啟恢復數據時間過長。

 

出處:https://www.cnblogs.com/javaguide/p/11824105.html


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM