摘要：結(jié)合對做如下調(diào)整的毫秒時間戳的數(shù)據(jù)邏輯分區(qū)以及的自增序列。為了解決這個問題，便引入了邏輯分區(qū)。參考文章批量插入返回自增的問題美團點評分布式生成系統(tǒng)

這里的博客版本都不會被更新維護。查看最新的版本請移步：http://neojos.com

全稱Universally Unique Identifier，UUID占128bit，也就是16個英文字符的長度（16byte），需要強調(diào)的是，它的生成無需中心處理程序。

UUID被用來標識URN(Uniform Resource Names)，對于Transaction ID以及其他需要唯一標志的場景都可以使用它。

UUID是空間和時間上的唯一標識，它長度固定，內(nèi)部中包含時間信息。如果服務(wù)器時間存在不同步的情況，UUID可能會出現(xiàn)重復(fù)。

基本格式，由6部分組成：

time-low - time-mide - time-high-and-version - clock-seq-and-reserved & clock-seq-low - node

一個URN示例：f81d4fae-7dec-11d0-a765-00a0c91e6bf6。

因為UUID占128bit，16進制數(shù)占4bit，所以轉(zhuǎn)換成16進制0-f的字符串總共有32位。組成的各個部分具體由幾位16進制表示，請查閱 Namespace Registration Template

因為UUID太長且無序，導(dǎo)致其不適合做MySQL的主鍵索引。而且MySQL自帶的auto-increment功能，選擇bigint的話也只占用64bit。

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.
If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

ObjectId由占4-byte的時間戳、3-byte的機器標識、2-byte的進程ID以及3-byte的計數(shù)組成，總共還是占用96bit。

這些ID組成包括時間、機器標識、隨機數(shù)，在UUID生成時還使用到MAC地址。這些參數(shù)中時間是關(guān)鍵，保證集群服務(wù)器的時鐘準確非常重要。

Twitter Snowflake生成的ID占64bit，跟bigint大小一致。由41 bit毫秒精度的時間戳、10bit的機器ID以及12 bit的序列號組成（計數(shù)每4096就重新開始一輪），剩下的1 bit奉獻給未來。

作者修改了它的原始設(shè)定，將剩下的1 bit給了時間戳。使用機器MAC地址的HASH值作為當(dāng)前機器的ID。

服務(wù)全局保存最近一次生成ID的時間戳lastTimestamp，作為生成新ID的判斷依據(jù)，避免時間回溯。詳細代碼請參照[1]。

// Block and wait till next millisecond
private long waitNextMillis(long currentTimestamp) {
    while (currentTimestamp == lastTimestamp) {
        currentTimestamp = timestamp();
    }
    return currentTimestamp;
}

同時將sequence也聲明為全局變量，每間隔4096次就重新開始計數(shù)。主要用于應(yīng)對：當(dāng)時間戳相同時保證生成的ID是不同的。

if (currentTimestamp == lastTimestamp) {
    sequence = (sequence + 1) & maxSequence;
    if(sequence == 0) {
        // Sequence Exhausted, wait till next millisecond.
        currentTimestamp = waitNextMillis(currentTimestamp);
    }
} else {
    // reset sequence to start with zero for the next millisecond
    sequence = 0;
}

該方式通過中心的DB服務(wù)來生成唯一自增ID，但DB服務(wù)的寫操作會成為系統(tǒng)的瓶頸。如果后臺是單個DB服務(wù)的話，存在單點問題。

參考Flickr的方法，后臺使用兩個DB來生成ID，其中auto-increment一個按照奇數(shù)步長增長，另一個按照偶數(shù)步長增長。MySQL內(nèi)部使用REPLACE來實現(xiàn)，通過一條沖突的記錄，來持續(xù)生成自增的主鍵ID。

REPLACE makes sense only if a table has a PRIMARY KEY or UNIQUE index. Otherwise, it becomes equivalent to INSERT, because there is no index to be used to determine whether a new row duplicates another.

結(jié)合Twitter Snowflake對ID做如下調(diào)整：41-bit的毫秒時間戳、13-bit的數(shù)據(jù)邏輯分區(qū)以及10-bit的自增序列。自增序列對1024取余，每個分區(qū)每毫秒內(nèi)能生成1024個自增ID。

Flickr中各個數(shù)據(jù)表按照不同的步長增長，當(dāng)需要分表的時候就會存在巨復(fù)雜的數(shù)據(jù)遷移問題。為了解決這個問題，便引入了邏輯分區(qū)Shard ID。通過邏輯上的Shard，將數(shù)據(jù)分散在不同的數(shù)據(jù)表中。這樣后續(xù)的分庫分表都可以通過操作邏輯上Shard來實現(xiàn)，將DB從具體的實現(xiàn)中解脫出來。

關(guān)于獲取MySQL自增ID，代碼無法批量獲取插入的全部自增ID列表，MySQL只會返回第一條記錄的自增ID。因為自增ID是連續(xù)的，所以可以通過計算的方式來計算出ID列表。

If you insert multiple rows using a single INSERT statement, LAST_INSERT_ID() returns the value generated for the first inserted row only. The reason for this is to make it possible to reproduce easily the same INSERT statement against some other server.

關(guān)于Shard可以查看本地緩存BigCache，很有參考意義（我覺得）。

文中介紹了ID的兩種生成方式，核心的區(qū)別在于：整個系統(tǒng)的ID是否支持單調(diào)遞增。Twitter Snowflake以及UUID可以保證生成的數(shù)據(jù)唯一，但多臺服務(wù)器的話，無法保證生成的數(shù)據(jù)有序。而Ticket Servers通過結(jié)合MySQL的auto-increment解決了這個問題。

參考文章：

Generating unique IDs in a distributed environment at high scale

A Universally Unique IDentifier (UUID) URN Namespace

Clustered and Secondary Indexes

Sharding & IDs at Instagram

Ticket Server: Distributed Unique Primary Keys on the Cheap

MySQL批量插入返回自增ID的問題

Leaf——美團點評分布式ID生成系統(tǒng)