分佈式中的分庫分表以後,ID 主鍵如何處理?

面試題

分庫分表以後,id 主鍵如何處理?(惟一性,排序等)html

面試官心理分析

其實這是分庫分表以後你必然要面對的一個問題,就是 id 咋生成?由於要是分紅多個表以後,每一個表都是從 1 開始累加,那確定不對啊,須要一個全局惟一的 id 來支持,排序問題等。因此這都是你實際生產環境中必須考慮的問題。java

面試題剖析

基於數據庫的實現方案

數據庫自增 id

這個就是說你的系統裏每次獲得一個 id,都是往一個庫的一個表裏插入一條沒什麼業務含義的數據,而後獲取一個數據庫自增的一個 id。拿到這個 id 以後再往對應的分庫分表裏去寫入。mysql

這個方案的好處就是方便簡單,誰都會用;缺點就是單庫生成自增 id,要是高併發的話,就會有瓶頸的;若是你硬是要改進一下,那麼就專門開一個服務出來,這個服務每次就拿到當前 id 最大值,而後本身遞增幾個 id,一次性返回一批 id,而後再把當前最大 id 值修改爲遞增幾個 id 以後的一個值;可是不管如何都是基於單個數據庫git

適合的場景:你分庫分表就倆緣由,要不就是單庫併發過高,要不就是單庫數據量太大;除非是你併發不高,可是數據量太大致使的分庫分表擴容,你能夠用這個方案,由於可能每秒最高併發最多就幾百,那麼就走單獨的一個庫和表生成自增主鍵便可。程序員

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

能夠經過設置數據庫 sequence 或者表的自增字段步長來進行水平伸縮。github

好比說,如今有 8 個服務節點,每一個服務節點使用一個 sequence 功能來產生 ID,每一個 sequence 的起始 ID 不一樣,而且依次遞增,步長都是 8。面試

file

適合的場景:在用戶防止產生的 ID 重複時,這種方案實現起來比較簡單,也能達到性能目標。可是服務節點固定,步長也固定,未來若是還要增長服務節點,就很差搞了。redis

UUID

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

適合的場景:若是你是要隨機生成個什麼文件名、編號之類的,你能夠用 UUID,可是做爲主鍵是不能用 UUID 的。sql

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,要怎麼操做呢? 第一,mysql一、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命令過得,致使重啓恢復數據時間過長。

 

出處:http://www.javashuo.com/article/p-mqxkfswy-ck.html

相關文章
相關標籤/搜索