高階Java開發必備：分佈式系統的惟一id生成算法你瞭解嗎？【石杉的架構筆記】

時間 2019-11-06

標籤高階 java 開發必備分佈式系統惟一生成算法瞭解石杉的架構筆記欄目 Java 简体版

原文原文鏈接

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）程序員

週一至週五早8點半！精品技術文章準時送上！面試

精品學習資料獲取通道，參見文末算法

「以前一篇文章，咱們聊了一下分庫分表相關的一些基礎知識，具體能夠參見：支撐日活百萬用戶的高併發系統，應該如何設計其數據庫架構？。數據庫

這篇文章，咱們就接着分庫分表的知識，來具體聊一下全局惟一id如何生成。緩存

在分庫分表以後你必然要面對的一個問題，就是id咋生成？性能優化

由於要是一個表分紅多個表以後，每一個表的id都是從1開始累加自增加，那確定不對啊。bash

舉個例子，你的訂單表拆分爲了1024張訂單表，每一個表的id都從1開始累加，這個確定有問題了！網絡

你的系統就沒辦法根據表主鍵來查詢訂單了，好比id = 50這個訂單，在每一個表裏都有！架構

因此此時就須要分佈式架構下的全局惟一id生成的方案了，在分庫分表以後，對於插入數據庫中的核心id，不能直接簡單使用表自增id，要全局生成惟一id，而後插入各個表中，保證每一個表內的某個id，全局惟一。併發

好比說訂單表雖然拆分爲了1024張表，可是id = 50這個訂單，只會存在於一個表裏。

那麼如何實現全局惟一id呢？有如下幾種方案。

（1）方案一：獨立數據庫自增id

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

好比說你有一個auto_id庫，裏面就一個表，叫作auto_id表，有一個id是自增加的。

那麼你每次要獲取一個全局惟一id，直接往這個表裏插入一條記錄，獲取一個全局惟一id便可，而後這個全局惟一id就能夠插入訂單的分庫分表中。

這個方案的好處就是方便簡單，誰都會用。缺點就是單庫生成自增id，要是高併發的話，就會有瓶頸的，由於auto_id庫要是承載個每秒幾萬併發，確定是不現實的了。

（2）方案二：uuid

這個每一個人都應該知道吧，就是用UUID生成一個全局惟一的id。

好處就是每一個系統本地生成，不要基於數據庫來了

很差之處就是，uuid太長了，做爲主鍵性能太差了，不適合用於主鍵。

若是你是要隨機生成個什麼文件名了，編號之類的，你能夠用uuid，可是做爲主鍵是不能用uuid的。

（3）方案三：獲取系統當前時間

這個方案的意思就是獲取當前時間做爲全局惟一的id。

可是問題是，併發很高的時候，好比一秒併發幾千，會有重複的狀況，這個是確定不合適的。

通常若是用這個方案，是將當前時間跟不少其餘的業務字段拼接起來，做爲一個id，若是業務上你以爲能夠接受，那麼也是能夠的。

你能夠將別的業務字段值跟當前時間拼接起來，組成一個全局惟一的編號，好比說訂單編號：時間戳 + 用戶id + 業務含義編碼。

（4）方案四：snowflake算法的思想分析

snowflake算法，是twitter開源的分佈式id生成算法。

其核心思想就是：使用一個64 bit的long型的數字做爲全局惟一id，這64個bit中，其中1個bit是不用的，而後用其中的41 bit做爲毫秒數，用10 bit做爲工做機器id，12 bit做爲序列號。

給你們舉個例子吧，好比下面那個64 bit的long型數字，你們看看

上面第一個部分，是1個bit：0，這個是無心義的

上面第二個部分是41個bit：表示的是時間戳

上面第三個部分是5個bit：表示的是機房id，10001

上面第四個部分是5個bit：表示的是機器id，1 1001

上面第五個部分是12個bit：表示的序號，就是某個機房某臺機器上這一毫秒內同時生成的id的序號，0000 00000000

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，也就是說能夠用這個12bit表明的數字來區分同一個毫秒內的4096個不一樣的id

簡單來講，你的某個服務假設要生成一個全局惟一id，那麼就能夠發送一個請求給部署了snowflake算法的系統，由這個snowflake算法系統來生成惟一id。

這個snowflake算法系統首先確定是知道本身所在的機房和機器的，好比機房id = 17，機器id = 12。

接着snowflake算法系統接收到這個請求以後，首先就會用二進制位運算的方式生成一個64 bit的long型id，64個bit中的第一個bit是無心義的。

接着41個bit，就能夠用當前時間戳（單位到毫秒），而後接着5個bit設置上這個機房id，還有5個bit設置上機器id。

最後再判斷一下，當前這臺機房的這臺機器上這一毫秒內，這是第幾個請求，給此次生成id的請求累加一個序號，做爲最後的12個bit。

最終一個64個bit的id就出來了，相似於：

這個算法能夠保證說，一個機房的一臺機器上，在同一毫秒內，生成了一個惟一的id。可能一個毫秒內會生成多個id，可是有最後12個bit的序號來區分開來。

下面咱們簡單看看這個snowflake算法的一個代碼實現，這就是個示例，你們若是理解了這個意思以後，之後能夠本身嘗試改造這個算法。

總之就是用一個64bit的數字中各個bit位來設置不一樣的標誌位，區分每個id。

（5）snowflake算法的代碼實現

public class IdWorker {
  private long workerId; // 這個就是表明了機器id
  private long datacenterId; // 這個就是表明了機房id
  private long sequence; // 這個就是表明了一毫秒內生成的多個id的最新序號
  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));
    }
    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();
  }
  // 這個是核心方法，經過調用nextId()方法，讓當前這臺機器上的snowflake算法程序生成一個全局惟一的id
  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));
    }
    
    // 下面是說假設在同一個毫秒內，又發送了一個請求生成一個id
    // 這個時候就得把seqence序號給遞增1，最多就是4096
    if (lastTimestamp == timestamp) {
    
      // 這個意思是說一個毫秒內最多隻能有4096個數字，不管你傳遞多少進來，
      //這個位運算保證始終就是在4096這個範圍內，避免你本身傳遞個sequence超過了4096這個範圍
      sequence = (sequence + 1) & sequenceMask; 
      if (sequence == 0) {
        timestamp = tilNextMillis(lastTimestamp);
      }
    
    } else {
      sequence = 0;
    }
    // 這兒記錄一下最近一次生成id的時間戳，單位是毫秒
    lastTimestamp = timestamp;
    // 這兒就是最核心的二進制位運算操做，生成一個64bit的id
    // 先將當前時間戳左移，放到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());
    }
  }
}
複製代碼

（6）snowflake算法一個小小的改進思路

其實在實際的開發中，這個snowflake算法能夠作一點點改進。

由於你們能夠考慮一下，咱們在生成惟一id的時候，通常都須要指定一個表名，好比說訂單表的惟一id。

因此上面那64個bit中，表明機房的那5個bit，可使用業務表名稱來替代，好比用00001表明的是訂單表。

由於其實不少時候，機房並無那麼多，因此那5個bit用作機房id可能意義不是太大。

這樣就能夠作到，snowflake算法系統的每一臺機器，對一個業務表，在某一毫秒內，能夠生成一個惟一的id，一毫秒內生成不少id，用最後12個bit來區分序號對待。

End

（封面圖源網絡，侵權刪除）

掃描下方二維碼，備註：「資料」，獲取更多「祕製」精品學習資料

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授