高階Java開發必備:分散式系統的唯一id生成演算法你瞭解嗎?【石杉的架構筆記】

石杉的架構筆記發表於2019-02-20

歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)

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

精品學習資料獲取通道,參見文末


“ 之前一篇文章,我們聊了一下分庫分表相關的一些基礎知識,具體可以參見:支撐日活百萬使用者的高併發系統,應該如何設計其資料庫架構?

這篇文章,我們就接著分庫分表的知識,來具體聊一下全域性唯一id如何生成。


在分庫分表之後你必然要面對的一個問題,就是id咋生成?

因為要是一個表分成多個表之後,每個表的id都是從1開始累加自增長,那肯定不對啊。

舉個例子,你的訂單表拆分為了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型數字,大家看看

高階Java開發必備:分散式系統的唯一id生成演算法你瞭解嗎?【石杉的架構筆記】

上面第一個部分,是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就出來了,類似於:


高階Java開發必備:分散式系統的唯一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

(封面圖源網路,侵權刪除)


掃描下方二維碼,備註:“資料”,獲取更多“祕製” 精品學習資料

高階Java開發必備:分散式系統的唯一id生成演算法你瞭解嗎?【石杉的架構筆記】

如有收穫,請幫忙轉發,您的鼓勵是作者最大的動力,謝謝!

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

歡迎掃描下方二維碼,持續關注:

高階Java開發必備:分散式系統的唯一id生成演算法你瞭解嗎?【石杉的架構筆記】

石杉的架構筆記(id:shishan100)

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

推薦閱讀:

1、拜託!面試請不要再問我Spring Cloud底層原理

2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?

3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰

4、微服務架構如何保障雙11狂歡下的99.99%高可用

5、兄弟,用大白話告訴你小白都能聽懂的Hadoop架構原理

6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問

7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍

8、拜託,面試請不要再問我TCC分散式事務的實現原理!

9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?

10、拜託,面試請不要再問我Redis分散式鎖的實現原理!

11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?

12、億級流量系統架構之如何支撐百億級資料的儲存與計算

13、億級流量系統架構之如何設計高容錯分散式計算系統

14、億級流量系統架構之如何設計承載百億流量的高效能架構

15、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

16、億級流量系統架構之如何設計全鏈路99.99%高可用架構

17、七張圖徹底講清楚ZooKeeper分散式鎖的實現原理

18、大白話聊聊Java併發面試問題之volatile到底是什麼?

19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能?

20、大白話聊聊Java併發面試問題之談談你對AQS的理解?

21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥?

22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

23、網際網路公司的面試官是如何360°無死角考察候選人的?(上篇)

24、網際網路公司面試官是如何360°無死角考察候選人的?(下篇)

25、Java進階面試系列之一:哥們,你們的系統架構中為什麼要引入訊息中介軟體?

26、【Java進階面試系列之二】:哥們,那你說說系統架構引入訊息中介軟體有什麼缺點?

27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

28、【Java進階面試系列之三】哥們,訊息中介軟體在你們專案裡是如何落地的?

29、【Java進階面試系列之四】扎心!線上服務當機時,如何保證資料100%不丟失?

30、一次JVM FullGC的背後,竟隱藏著驚心動魄的線上生產事故!

31、【高併發優化實踐】10倍請求壓力來襲,你的系統會被擊垮嗎?

32、【Java進階面試系列之五】訊息中介軟體叢集崩潰,如何保證百萬生產資料不丟失?

33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?

34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?

35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?

36、億級流量架構第二彈:你的系統真的無懈可擊嗎?

37、億級流量系統架構之如何保證百億流量下的資料一致性(上)

38、億級流量系統架構之如何保證百億流量下的資料一致性(中)?

39、億級流量系統架構之如何保證百億流量下的資料一致性(下)?

40、網際網路面試必殺:如何保證訊息中介軟體全鏈路資料100%不丟失(1)

41、網際網路面試必殺:如何保證訊息中介軟體全鏈路資料100%不丟失(2

42、面試大殺器:訊息中介軟體如何實現消費吞吐量的百倍優化?

43、高併發場景下,如何保證生產者投遞到訊息中介軟體的訊息不丟失?

44、兄弟,用大白話給你講小白都能看懂的分散式系統容錯架構

45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化

46、【非廣告,純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件?

47、如果20萬使用者同時訪問一個熱點快取,如何優化你的快取架構?

48、【非廣告,純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT?

49、拜託,面試請不要再問我分散式搜尋引擎的架構原理!

50、【金三銀四跳槽季】Java工程師如何在1個月內做好面試準備?

51、【offer收割機必備】我簡歷上的Java專案都好low,怎麼辦?

52、【offer去哪了】我一連面試了十個Java崗,統統石沉大海!


作者:石杉的架構筆記
連結:https://juejin.im/post/5c6a9f25518825787e69e70a
來源:掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。


相關文章