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

摘要介紹來自flicker和twitter的兩種解決分布式環境下全域性id生成方案。

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

因為mysql本身支援auto_increment操作，很自然地，我們會想到借助這個特性來實現這個功能。flicker在解決全域性id生成方案裡就採用了mysql自增長id的機制（auto_increment + replace into + myisam）。乙個生成64位id方案具體就是這樣的：

先建立單獨的資料庫(eg:ticket)，然後建立乙個表：

create
table
tickets64 (
idbigint
(20) unsigned
notnull
auto_increment,
stub char
(1) not
null
default
'',primary key
(id), unique
keystub (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就可以了。

參考：

41位的時間序列（精確到毫秒，41位的長度可以使用69年） 10位的機器標識（10位的長度最多支援部署1024個節點）

12位的計數順序號（12位的計數順序號支援每個節點每毫秒產生4096個id序號）最高位是符號位，始終為0。

可參考

使用佇列服務，如redis、memcacheq等等，將一定量的id預分配在乙個佇列裡，每次插入操作，先從佇列中獲取乙個id，若插入失敗的話，將該id再次新增到佇列中，同時監控佇列數量，當小於閥值時，自動向佇列中新增元素。

這種方式可以有規劃的對id進行分配，還會帶來經濟效應，比如ｑｑ號碼，各種靚號，明碼標價。如**的userid, 允許uid登陸，推出各種靚號，明碼標價，對於普通的id打亂後再隨機分配。

詳細參見——

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

mysql分表分庫實現 MySql分表分庫思路

MySQL範圍分表分庫 mysql 分表分庫策略

mysql 分庫分表實戰 MySQL分庫分表實戰

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

mysql分表分庫實現 MySql分表分庫思路

MySQL範圍分表分庫 mysql 分表分庫策略

mysql 分庫分表實戰 MySQL分庫分表實戰

相關推薦