高併發分佈式系統中生成全局惟一Id彙總

數據在分片時，典型的是分庫分表，就有一個全局ID生成的問題。
單純的生成全局ID並非什麼難題，可是生成的ID一般要知足分片的一些要求：
   1 不能有單點故障。
   2 以時間爲序，或者ID裏包含時間。這樣一是能夠少一個索引，二是冷熱數據容易分離。
   3 能夠控制ShardingId。好比某一個用戶的文章要放在同一個分片內，這樣查詢效率高，修改也容易。
   4 不要太長，最好64bit。使用long比較好操做，若是是96bit，那就要各類移位至關的不方便，還有可能有些組件不能支持這麼大的ID。

一 twitter
twitter在把存儲系統從MySQL遷移到Cassandra的過程當中因爲Cassandra沒有順序ID生成機制，因而本身開發了一套全局惟一ID生成服務：Snowflake。
1 41位的時間序列（精確到毫秒，41位的長度可使用69年）
2 10位的機器標識（10位的長度最多支持部署1024個節點）
3 12位的計數順序號（12位的計數順序號支持每一個節點每毫秒產生4096個ID序號） 最高位是符號位，始終爲0。
優勢：高性能，低延遲；獨立的應用；按時間有序。 缺點：須要獨立的開發和部署。

原理

java 實現代碼

public class IdWorker {

private final long workerId;
private final static long twepoch = 1288834974657L;
private long sequence = 0L;
private final static long workerIdBits = 4L;
public final static long maxWorkerId = -1L ^ -1L << workerIdBits;
private final static long sequenceBits = 10L;
private final static long workerIdShift = sequenceBits;
private final static long timestampLeftShift = sequenceBits + workerIdBits;
public final static long sequenceMask = -1L ^ -1L << sequenceBits;
private long lastTimestamp = -1L;
public IdWorker(final long workerId) {
super();
if (workerId > this.maxWorkerId || workerId < 0) {
throw new IllegalArgumentException(String.format(
"worker Id can't be greater than %d or less than 0",
this.maxWorkerId));
}
this.workerId = workerId;
}
public synchronized long nextId() {
long timestamp = this.timeGen();
if (this.lastTimestamp == timestamp) {
this.sequence = (this.sequence + 1) & this.sequenceMask;
if (this.sequence == 0) {
System.out.println("###########" + sequenceMask);
timestamp = this.tilNextMillis(this.lastTimestamp);
}
} else {
this.sequence = 0;
}
if (timestamp < this.lastTimestamp) {
try {
throw new Exception(
String.format(
"Clock moved backwards. Refusing to generate id for %d milliseconds",
this.lastTimestamp - timestamp));
} catch (Exception e) {
e.printStackTrace();
}
}

this.lastTimestamp = timestamp;
long nextId = ((timestamp - twepoch << timestampLeftShift))
| (this.workerId << this.workerIdShift) | (this.sequence);
System.out.println("timestamp:" + timestamp + ",timestampLeftShift:"
+ timestampLeftShift + ",nextId:" + nextId + ",workerId:"
+ workerId + ",sequence:" + sequence);
return nextId;
}

private long tilNextMillis(final long lastTimestamp) {
long timestamp = this.timeGen();
while (timestamp <= lastTimestamp) {
timestamp = this.timeGen();
}
return timestamp;
}

private long timeGen() {
return System.currentTimeMillis();
}


public static void main(String[] args){
IdWorker worker2 = new IdWorker(2);
System.out.println(worker2.nextId());
}

}

2 來自Flicker的解決方案
由於MySQL自己支持auto_increment操做，很天然地，咱們會想到藉助這個特性來實現這個功能。
Flicker在解決全局ID生成方案裏就採用了MySQL自增加ID的機制（auto_increment + replace into + MyISAM）。一個生成64位ID方案具體就是這樣的：
先建立單獨的數據庫(eg:ticket)，而後建立一個表：

CREATE TABLE Tickets64 (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(1) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
) ENGINE=MyISAM

　　

當咱們插入記錄後，執行SELECT * from Tickets64，查詢結果就是這樣的：

+-------------------+------+
| id | stub |
+-------------------+------+
| 72157623227190423 | a |
+-------------------+------+
在咱們的應用端須要作下面這兩個操做，在一個事務會話裏提交：

REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();

這樣咱們就能拿到不斷增加且不重複的ID了。
到上面爲止，咱們只是在單臺數據庫上生成ID，從高可用角度考慮，接下來就要解決單點故障問題：Flicker啓用了兩臺數據庫服務器來生成ID，經過區分auto_increment的起始值和步長來生成奇偶數的ID。

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

最後，在客戶端只須要經過輪詢方式取ID就能夠了。

優點：充分藉助數據庫的自增ID機制，提供高可靠性，生成的ID有序。
缺點：佔用兩個獨立的MySQL實例，有些浪費資源，成本較高。

三 UUID

UUID生成的是length=32的16進制格式的字符串，若是回退爲byte數組共16個byte元素，即UUID是一個128bit長的數字，
通常用16進製表示。
算法的核心思想是結合機器的網卡、當地時間、一個隨即數來生成UUID。
從理論上講，若是一臺機器每秒產生10000000個GUID，則能夠保證（機率意義上）3240年不重複
優勢：
（1）本地生成ID，不須要進行遠程調用，時延低
（2）擴展性好，基本能夠認爲沒有性能上限
缺點：
（1）沒法保證趨勢遞增
（2）uuid過長，每每用字符串表示，做爲主鍵創建索引查詢效率低，常見優化方案爲「轉化爲兩個uint64整數存儲」或者「折半存儲」（折半後不能保證惟一性）
四 基於redis的分佈式ID生成器
首先，要知道redis的EVAL，EVALSHA命令：
原理

利用redis的lua腳本執行功能，在每一個節點上經過lua腳本生成惟一ID。
生成的ID是64位的：

使用41 bit來存放時間，精確到毫秒，可使用41年。
使用12 bit來存放邏輯分片ID，最大分片ID是4095
使用10 bit來存放自增加ID，意味着每一個節點，每毫秒最多能夠生成1024個ID
好比GTM時間 Fri Mar 13 10:00:00 CST 2015 ，它的距1970年的毫秒數是 1426212000000，假定分片ID是53，自增加序列是4，則生成的ID是：

5981966696448054276 = 1426212000000 << 22 + 53 << 10 + 41
redis提供了TIME命令，能夠取得redis服務器上的秒數和微秒數。因些lua腳本返回的是一個四元組。

second, microSecond, partition, seq
客戶端要本身處理，生成最終ID。

((second * 1000 + microSecond / 1000) << (12 + 10)) + (shardId << 10) + seq;
五 MongoDB文檔（Document）全局惟一ID

爲了考慮分佈式，「_id」要求不一樣的機器都能用全局惟一的同種方法方便的生成它。所以不能使用自增主鍵（須要多臺服務器進行同步，既費時又費力），
所以選用了生成ObjectId對象的方法。

ObjectId使用12字節的存儲空間，其生成方式以下：

|0|1|2|3|4|5|6 |7|8|9|10|11|

|時間戳 |機器ID|PID|計數器 |

前四個字節時間戳是從標準紀元開始的時間戳，單位爲秒，有以下特性：

 1 時間戳與後邊5個字節一塊，保證秒級別的惟一性；
 2 保證插入順序大體按時間排序；
 3 隱含了文檔建立時間；
 4 時間戳的實際值並不重要，不須要對服務器之間的時間進行同步（由於加上機器ID和進程ID已保證此值惟一，惟一性是ObjectId的最終訴求）。

機器ID是服務器主機標識，一般是機器主機名的散列值。

同一臺機器上能夠運行多個mongod實例，所以也須要加入進程標識符PID。

前9個字節保證了同一秒鐘不一樣機器不一樣進程產生的ObjectId的惟一性。後三個字節是一個自動增長的計數器（一個mongod進程須要一個全局的計數器），保證同一秒的ObjectId是惟一的。同一秒鐘最多容許每一個進程擁有（256^3 = 16777216）個不一樣的ObjectId。

總結一下：時間戳保證秒級惟一，機器ID保證設計時考慮分佈式，避免時鐘同步，PID保證同一臺服務器運行多個mongod實例時的惟一性，最後的計數器保證同一秒內的惟一性（選用幾個字節既要考慮存儲的經濟性，也要考慮併發性能的上限）。

"_id"既能夠在服務器端生成也能夠在客戶端生成，在客戶端生成能夠下降服務器端的壓力。