全域性唯一的 ID 幾乎是所有系統都會遇到的剛需。這個 id 在搜尋, 儲存資料, 加快檢索速度 等等很多方面都有著重要的意義。工業上有多種策略來獲取這個全域性唯一的id，針對常見的幾種場景，我在這裡進行簡單的總結和對比。

簡單分析一下需求 [1]

所謂全域性唯一的 id 其實往往對應是生成唯一記錄標識的業務需求。

這個 id 常常是資料庫的主鍵，資料庫上會建立聚集索引（cluster index），即在物理儲存上以這個欄位排序。這個記錄標識上的查詢，往往又有分頁或者排序的業務需求。所以往往要有一個time欄位，並且在time欄位上建立普通索引（non-cluster index）。普通索引儲存的是實際記錄的指標，其訪問效率會比聚集索引慢，如果記錄標識在生成時能夠基本按照時間有序，則可以省去這個time欄位的索引查詢。

這就引出了記錄標識生成的兩大核心需求：

• 全域性唯一
• 趨勢有序

常見生成策略的優缺點對比 [2]

方法一: 用資料庫的 auto_increment 來生成

優點：

1. 此方法使用資料庫原有的功能，所以相對簡單
2. 能夠保證唯一性
3. 能夠保證遞增性
4. id 之間的步長是固定且可自定義的

缺點：

1. 可用性難以保證：資料庫常見架構是 一主多從 + 讀寫分離，生成自增ID是寫請求 主庫掛了就玩不轉了
2. 擴充套件性差，效能有上限：因為寫入是單點，資料庫主庫的寫效能決定ID的生成效能上限，並且 難以擴充套件

改進方案：

• 冗餘主庫，避免寫入單點
• 資料水平切分，保證各主庫生成的ID不重複

  方法一改進方案的結構圖

  如上圖所述，由1個寫庫變成3個寫庫，每個寫庫設定不同的 auto_increment 初始值，以及相同的增長步長
  ，以保證每個資料庫生成的ID是不同的（上圖中DB 01生成0,3,6,9…，DB 02生成1,4,7,10，DB 03生成2,5,8,11…）

改進後的架構保證了可用性，但缺點是

• 喪失了ID生成的“絕對遞增性”：先訪問DB 01生成0,3，再訪問DB 02生成1，可能導致在非常短的時間內，ID生成不是絕對遞增的（這個問題不大，目標是趨勢遞增，不是絕對遞增
• 資料庫的寫壓力依然很大，每次生成ID都要訪問資料庫

為了解決這些問題，引出了以下方法：

方法二：單點批量ID生成服務

分散式系統之所以難，很重要的原因之一是“沒有一個全域性時鐘，難以保證絕對的時序”，要想保證絕對的時序，還是隻能使用單點服務，用本地時鐘保證“絕對時序”。
資料庫寫壓力大，是因為每次生成ID都訪問了資料庫，可以使用批量的方式降低資料庫寫壓力

ID生成服務假設每次批量拉取5個ID，服務訪問資料庫，將當前ID的最大值修改為4，這樣應用訪問ID生成服務索要ID，ID生成服務不需要每次訪問資料庫，就能依次派發0,1,2,3,4這些ID了。

當ID發完後，再將ID的最大值修改為11，就能再次派發6,7,8,9,10,11這些ID了，於是資料庫的壓力就降低到原來的1/6。

優點：

• 保證了ID生成的絕對遞增有序
• 大大的降低了資料庫的壓力，ID生成可以做到每秒生成幾萬幾十萬個

缺點：

• 服務仍然是單點
• 如果服務掛了，服務重啟起來之後，繼續生成ID可能會不連續，中間出現空洞（服務記憶體是儲存著0,1,2,3,4，資料庫中max-id是4，分配到3時，服務重啟了，下次會從5開始分配，3和4就成了空洞，不過這個問題也不大）
• 雖然每秒可以生成幾萬幾十萬個ID，但畢竟還是有效能上限，無法進行水平擴充套件

改進方案

單點服務的常用高可用優化方案是“備用服務”，也叫“影子服務”，所以我們能用以下方法優化上述缺點：

方法三：uuid / guid

不管是通過資料庫，還是通過服務來生成ID，業務方Application都需要進行一次遠端呼叫，比較耗時。uuid是一種常見的本地生成ID的方法。

優點：

• 本地生成ID，不需要進行遠端呼叫，時延低
• 擴充套件性好，基本可以認為沒有效能上限

缺點：

• 無法保證趨勢遞增
• uuid過長，往往用字串表示，作為主鍵建立索引查詢效率低，常見優化方案為“轉化為兩個uint64整數儲存”或者“折半儲存”（折半後不能保證唯一性）

方法四：取當前毫秒數

uuid是一個本地演算法，生成效能高，但無法保證趨勢遞增，且作為字串ID檢索效率低，有沒有一種能保證遞增的本地演算法呢？ - 取當前毫秒數是一種常見方案。

優點：

• 本地生成ID，不需要進行遠端呼叫，時延低
• 生成的ID趨勢遞增
• 生成的ID是整數，建立索引後查詢效率高

缺點：

• 如果併發量超過1000，會生成重複的ID

這個缺點要了命了，不能保證ID的唯一性。當然，使用微秒可以降低衝突概率，但每秒最多隻能生成1000000個ID，再多的話就一定會衝突了，所以使用微秒並不從根本上解決問題。

方法五：使用 Redis 來生成 id

當使用資料庫來生成ID效能不夠要求的時候，我們可以嘗試使用Redis來生成ID。這主要依賴於Redis是單執行緒的，所以也可以用生成全域性唯一的ID。可以用Redis的原子操作 INCR 和 INCRBY 來實現。

優點：

• 依賴於資料庫，靈活方便，且效能優於資料庫。
• 數字ID天然排序，對分頁或者需要排序的結果很有幫助。

缺點：

• 如果系統中沒有Redis，還需要引入新的元件，增加系統複雜度。
• 需要編碼和配置的工作量比較大。

方法六：Twitter 開源的 Snowflake 演算法

snowflake 是 twitter 開源的分散式ID生成演算法，其核心思想為，一個long型的ID：

• 41 bit 作為毫秒數 - 41位的長度可以使用69年
• 10 bit 作為機器編號 （5個bit是資料中心，5個bit的機器ID） - 10位的長度最多支援部署1024個節點

• 12 bit 作為毫秒內序列號 - 12位的計數順序號支援每個節點每毫秒產生4096個ID序號

  

  Snowflake圖示

  演算法單機每秒內理論上最多可以生成1000*(2^12)，也就是400W的ID，完全能滿足業務的需求。

  該演算法 java 版本的實現程式碼如下：

package com;
public class SnowflakeIdGenerator {
//================================================Algorithm's Parameter=============================================
    // 系統開始時間截 (UTC 2017-06-28 00:00:00)
private final long startTime = 1498608000000L;
// 機器id所佔的位數
private final long workerIdBits = 5L;
// 資料標識id所佔的位數
private final long dataCenterIdBits = 5L;
// 支援的最大機器id(十進位制)，結果是31 (這個移位演算法可以很快的計算出幾位二進位制數所能表示的最大十進位制數)
    // -1L 左移 5位 (worker id 所佔位數) 即 5位二進位制所能獲得的最大十進位制數 - 31
private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 支援的最大資料標識id - 31
private final long maxDataCenterId = -1L ^ (-1L << dataCenterIdBits);
// 序列在id中佔的位數
private final long sequenceBits = 12L;
// 機器ID 左移位數 - 12 (即末 sequence 所佔用的位數)
private final long workerIdMoveBits = sequenceBits;
// 資料標識id 左移位數 - 17(12+5)
private final long dataCenterIdMoveBits = sequenceBits + workerIdBits;
// 時間截向 左移位數 - 22(5+5+12)
private final long timestampMoveBits = sequenceBits + workerIdBits + dataCenterIdBits;
// 生成序列的掩碼(12位所對應的最大整數值)，這裡為4095 (0b111111111111=0xfff=4095)
private final long sequenceMask = -1L ^ (-1L << sequenceBits);
//=================================================Works's Parameter================================================
/**
     * 工作機器ID(0~31)
     */
private long workerId;
/**
     * 資料中心ID(0~31)
     */
private long dataCenterId;
/**
     * 毫秒內序列(0~4095)
     */
private long sequence = 0L;
/**
     * 上次生成ID的時間截
*/
private long lastTimestamp = -1L;
//===============================================Constructors=======================================================
/**
     * 建構函式
*
     * @param workerId     工作ID (0~31)
     * @param dataCenterId 資料中心ID (0~31)
     */
public SnowflakeIdGenerator(long workerId, long dataCenterId) {
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;
}
// ==================================================Methods========================================================
    // 執行緒安全的獲得下一個 ID 的方法
public synchronized long nextId() {
long timestamp = currentTime();
//如果當前時間小於上一次ID生成的時間戳: 說明系統時鐘回退過 - 這個時候應當丟擲異常
if (timestamp < lastTimestamp) {
throw new RuntimeException(
String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
}
//如果是同一時間生成的，則進行毫秒內序列
if (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask;
//毫秒內序列溢位 即 序列 > 4095
if (sequence == 0) {
//阻塞到下一個毫秒,獲得新的時間戳
timestamp = blockTillNextMillis(lastTimestamp);
}
        }
//時間戳改變，毫秒內序列重置
else {
sequence = 0L;
}
//上次生成ID的時間截
lastTimestamp = timestamp;
//移位並通過或運算拼到一起組成64位的ID
return ((timestamp - startTime) << timestampMoveBits) //
| (dataCenterId << dataCenterIdMoveBits) //
| (workerId << workerIdMoveBits) //
| sequence;
}
// 阻塞到下一個毫秒 即 直到獲得新的時間戳
protected long blockTillNextMillis(long lastTimestamp) {
long timestamp = currentTime();
while (timestamp <= lastTimestamp) {
timestamp = currentTime();
}
return timestamp;
}
// 獲得以毫秒為單位的當前時間
protected long currentTime() {
return System.currentTimeMillis();
}
//====================================================Test Case=====================================================
public static void main(String[] args) {
SnowflakeIdGenerator idWorker = new SnowflakeIdGenerator(0, 0);
for (int i = 0; i < 100; i++) {
long id = idWorker.nextId();
//System.out.println(Long.toBinaryString(id));
System.out.println(id);
}
    }

}

轉載自:

https://gavinlee1.github.io/2017/06/28/%E5%B8%B8%E8%A7%81%E5%88%86%E5%B8%83%E5%BC%8F%E5%85%A8%E5%B1%80%E5%94%AF%E4%B8%80ID%E7%94%9F%E6%88%90%E7%AD%96%E7%95%A5%E5%8F%8A%E7%AE%97%E6%B3%95%E7%9A%84%E5%AF%B9%E6%AF%94/

https://item.taobao.com/item.htm?spm=a1z10.1-c.w4004-18045781879.2.33c5236bZlPDUM&id=569353717228
深入理解Java虛擬機器（jvm效能調優+記憶體模型+虛擬機器原理）   很不錯的虛擬機器視訊教程.