在大型互聯(lián)網(wǎng)應用中，隨著用戶數(shù)的增加，為了提高應用的性能，我們經(jīng)常需要對數(shù)據(jù)庫進行分庫分表操作。在單表時代，我們可以完全依賴于數(shù)據(jù)庫的自增ID來唯一標識一個用戶或數(shù)據(jù)對象。但是當我們對數(shù)據(jù)庫進行了分庫分表后，就不能依賴于每個表的自增ID來全局唯一標識這些數(shù)據(jù)了。因此，我們需要提供一個全局唯一的ID號生成策略來支持分庫分表的環(huán)境。下面來介紹兩種非常優(yōu)秀的解決方案：

　　1. 數(shù)據(jù)庫自增ID--來自Flicker的解決方案

　　因為MySQL本身支持auto_increment操作，很自然地，我們會想到借助這個特性來實現(xiàn)這個功能。Flicker在解決全局ID生成方案里就采用了MySQL自增長ID的機制（auto_increment + replace into + MyISAM）。一個生成64位ID方案具體就是這樣的：

　　先創(chuàng)建單獨的數(shù)據(jù)庫（eg:ticket），然后創(chuàng)建一個表：

　　1 CREATE TABLE Tickets64

　　2 id bigint（20） unsigned NOT NULL auto_increment,

　　3 stub char（1） NOT NULL default '',

　　4 PRIMARY KEY （id），

　　5 UNIQUE KEY stub （stub）

　　6 ）

　　ENGINE=MyISAM 當我們插入記錄后，執(zhí)行SELECT * from Tickets64,查詢結果就是這樣的：

　　1 +-------------------+------+

　　2 | id

　　| stub |

　　3 +-------------------+------+

　　4 | 72157623227190423 |

　　a |

　　5 +-------------------+------+ 在我們的應用端需要做下面這兩個操作，在一個事務會話里提交 托福答案

　　1 REPLACE INTO Tickets64 （stub） VALUES （'a'）；

　　2 SELECT LAST_INSERT_ID（）；

　　這樣我們就能拿到不斷增長且不重復的ID了。

　　到上面為止，我們只是在單臺數(shù)據(jù)庫上生成ID,從高可用角度考慮，接下來就要解決單點故障問題：Flicker啟用了兩臺數(shù)據(jù)庫服務器來生成ID,通過區(qū)分auto_increment的起始值和步長來生成奇偶數(shù)的ID.

　　1 TicketServer1:

　　2 auto-increment-increment = 2

　　3 auto-increment-offset = 1

　　4

　　5 TicketServer2:

　　6 auto-increment-increment = 2

　　7 auto-increment-offset = 2

　　最后，在客戶端只需要通過輪詢方式取ID就可以了。

　　優(yōu)點：充分借助數(shù)據(jù)庫的自增ID機制，提供高可靠性，生成的ID有序。

　　缺點：占用兩個獨立的MySQL實例，有些浪費資源，成本較高。

　　2. 獨立的應用程序--來自Twitter的解決方案

　　Twitter在把存儲系統(tǒng)從MySQL遷移到Cassandra的過程中由于Cassandra沒有順序ID生成機制，于是自己開發(fā)了一套全局唯一ID生成服務：Snowflake.根據(jù)twitter的業(yè)務需求，snowflake系統(tǒng)生成64位的ID.由3部分組成：

　　1

　　41位的時間序列（精確到毫秒，41位的長度可以使用69年）

　　2

　　10位的機器標識（10位的長度最多支持部署1024個節(jié)點）

　　3

　　12位的計數(shù)順序號（12位的計數(shù)順序號支持每個節(jié)點每毫秒產(chǎn)生4096個ID序號）

　　優(yōu)點：高性能，低延遲；獨立的應用；按時間有序。

　　缺點：需要獨立的開發(fā)和部署。

MySQL分庫分表環(huán)境下全局ID生成方案