分佈式系統ID生成方案

自增ID

不錯，能夠限度抑制ID的大小。但須要有一箇中心化的節點做爲解決原子性問題。能夠選用Redis，MySQL，Zookeeper。成本有點高。

 

UUID

分佈式，並且惟一！缺點是生產的ID太長。

 

Twitter的SnowFlake算法

該算法能夠生產分佈式的自增ID。切生產的ID只有8字節，64位。其數據結構以下：

• 1位，不用。二進制中最高位爲1的都是負數，可是咱們生成的id通常都使用整數，因此這個最高位固定是0

• 41位，用來記錄時間戳（毫秒）。

  • 41位能夠表示241−1個數字，
  • 若是隻用來表示正整數（計算機中正數包含0），能夠表示的數值範圍是：0 至 241−1，減1是由於可表示的數值範圍是從0開始算的，而不是1。
  • 也就是說41位能夠表示241−1個毫秒的值，轉化成單位年則是(241−1)/(1000∗60∗60∗24∗365)=69年

• 10位，用來記錄工做機器id。

  • 能夠部署在210=1024個節點，包括5位datacenterId和5位workerId
  • 5位（bit）能夠表示的最大正整數是25−1=31，便可以用0、一、二、三、....31這32個數字，來表示不一樣的datecenterId或workerId

• 12位，序列號，用來記錄同毫秒內產生的不一樣id。

  • 12位（bit）能夠表示的最大正整數是212−1=4095，便可以用0、一、二、三、....4094這4095個數字，來表示同一機器同一時間截（毫秒)內產生的4095個ID序號

因爲在Java中64bit的整數是long類型，因此在Java中SnowFlake算法生成的id就是long來存儲的。

該算法生產的Id是在每臺機器上都是按時間戳自增的。

能夠根據實際需求變更該算法：好比能夠工做機器Id長度。擴大序列號和時間戳。