MySQL分庫分表環境下全局ID生成方案

在大型互聯網應用中，隨着用戶數的增長，爲了提升應用的性能，咱們常常須要對數據庫進行分庫分表操做。在單表時代，咱們能夠徹底依賴於數據庫的自增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實例，有些浪費資源，成本較高。

參考：http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

###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。

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

推薦閱讀：MySQL使用優化與總結