在大型網際網路應用中，隨著使用者數的增加，為了提高應用的效能，我們經常需要對資料庫進行分庫分表操作。在單表時代，我們可以完全依賴於資料庫的自增ID來唯一標識一個使用者或資料物件。但是當我們對資料庫進行了分庫分表後，就不能依賴於每個表的自增ID來全域性唯一標識這些資料了。因此，我們需要提供一個全域性唯一的ID號生成策略來支援分庫分表的環境。下面來介紹兩種非常優秀的解決方案：

1. 資料庫自增ID——來自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例項，有些浪費資源，成本較高。

2. 獨立的應用程式——來自Twitter的解決方案

Twitter在把儲存系統從MySQL遷移到Cassandra的過程中由於Cassandra沒有順序ID生成機制，於是自己開發了一套全域性唯一ID生成服務：Snowflake。GitHub地址：https://github.com/twitter/snowflake。根據twitter的業務需求，snowflake系統生成64位的ID。由3部分組成：

41位的時間序列（精確到毫秒，41位的長度可以使用69年）
10位的機器標識（10位的長度最多支援部署1024個節點）
12位的計數順序號（12位的計數順序號支援每個節點每毫秒產生4096個ID序號）

最高位是符號位，始終為0。

• 優點：高效能，低延遲；獨立的應用；按時間有序。
• 缺點：需要獨立的開發和部署。

3. 在Twitter基礎上的改進

可參考 http://geek.csdn.net/news/detail/72973

4. 使用快取佇列

使用佇列服務，如redis、memcacheq等等，將一定量的ID預分配在一個佇列裡，每次插入操作，先從佇列中獲取一個ID，若插入失敗的話，將該ID再次新增到佇列中，同時監控佇列數量，當小於閥值時，自動向佇列中新增元素。
這種方式可以有規劃的對ID進行分配，還會帶來經濟效應，比如ＱＱ號碼，各種靚號，明碼標價。如網站的userid, 允許uid登陸，推出各種靚號，明碼標價，對於普通的ID打亂後再隨機分配。

5.在Redis中使用lua指令碼

詳細參見——http://blog.csdn.net/hengyunabc/article/details/19025973