生產系統隨著業務增長總會經歷一個業務量由小變大的過程,可擴展性是考量數據庫系統高可用性的一個重要指標;在單表/數據庫數據量過大,更新量不斷飙漲時,MySQL DBA往往會對業務系統提出sharding的方案。既然要sharding,那麼不可避免的要討論到sharding key問題,在有些業務系統中,必須保證sharding key全局唯一,比如存放商品的數據庫等,那麼如何生成全局唯一的ID呢,下文將從DBA的角度介紹幾種常見的方案。
1、使用CAS思想
什麼是CAS協議
Memcached於1.2.4版本新增CAS(Check and Set)協議類同於Java並發的CAS(Compare and Swap)原子操作,處理同一item被多個線程更改過程的並發問題
CAS的基本原理
基本原理非常簡單,一言以蔽之,就是“版本號”,每個存儲的數據對象,都有一個版本號。
我們可以從下面的例子來理解:
不采用CAS,則有如下的情景:
•第一步,A取出數據對象X;
•第二步,B取出數據對象X;
•第三步,B修改數據對象X,並將其放入緩存;
•第四步,A修改數據對象X,並將其放入緩存。
結論:第四步中會產生數據寫入沖突。
采用CAS協議,則是如下的情景。
•第一步,A取出數據對象X,並獲取到CAS-ID1;
•第二步,B取出數據對象X,並獲取到CAS-ID2;
•第三步,B修改數據對象X,在寫入緩存前,檢查CAS-ID與緩存空間中該數據的CAS-ID是否一致。結果是“一致”,就將修改後的帶有CAS-ID2的X寫入到緩存。
•第四步,A修改數據對象Y,在寫入緩存前,檢查CAS-ID與緩存空間中該數據的CAS-ID是否一致。結果是“不一致”,則拒絕寫入,返回存儲失敗。
這樣CAS協議就用了“版本號”的思想,解決了沖突問題。(樂觀鎖概念)
其實這裡並不是嚴格的CAS,而是使用了比較交換原子操作的思想。
生成思路如下:每次生成全局id時,先從sequence表中獲取當前的全局最大id。然後在獲取的全局id上做加1操作,加1後的值更新到數據庫,如加1後的值為203,表名是users,數據表結構如下:
CREATE TABLE `SEQUENCE` ( `name` varchar(30) NOT NULL COMMENT '分表的表名', `gid` bigint(20) NOT NULL COMMENT '最大全局id', PRIMARY KEY (`name`) ) ENGINE=innodb
sql語句
update sequence set gid = 203 where name = 'users' and gid < 203;
sql語句的 and gid < 203 是為了保證並發環境下gid的值只增不減。
如果update語句的影響記錄條數為0說明,已經有其他進程提前生成了203這個值,並寫入了數據庫。需要重復以上步驟從新生成。
代碼實現如下:
//$name 表名
function next_id_db($name){
//獲取數據庫全局sequence對象
$seq_dao = Wk_Sequence_Dao_Sequence::getInstance();
$threshold = 100; //最大嘗試次數
for($i = 0; $i < $threshold; $i++){
$last_id = $seq_dao->get_seq_id($name);//從數據庫獲取全局id
$id = $last_id +1;
$ret = $seq_dao->set_seq_id($name, $id);
if($ret){
return $id;
break;
}
}
return false;
}
2、使用全局鎖
在進行並發編程時,一般都會使用鎖機制。其實,全局id的生成也是解決並發問題。
生成思路如下:
在使用redis的setnx方法和memcace的add方法時,如果指定的key已經存在,則返回false。利用這個特性,實現全局鎖
每次生成全局id前,先檢測指定的key是否存在,如果不存在則使用redis的incr方法或者memcache的increment進行加1操作。這兩個方法的返回值是加1後的值,如果存在,則程序進入循環等待狀態。循環過程中不斷檢測key是否還存在,如果key不存在就執行上面的操作。
代碼如下:
//使用redis實現
//$name 為 邏輯表名
function next_id_redis($name){
$redis = Wk_Redis_Util::getRedis();//獲取redis對象
$seq_dao = Wk_Sequence_Dao_Sequence::getInstance();//獲取存儲全局id數據表對象
if(!is_object($redis)){
throw new Exception("fail to create redis object");
}
$max_times = 10; //最大執行次數 避免redis不可用的時候 進入死循環
while(1){
$i++;
//檢測key是否存在,相當於檢測鎖是否存在
$ret = $redis->setnx("sequence_{$name}_flag",time());
if($ret){
break;
}
if($i > $max_times){
break;
}
$time = $redis->get("sequence_{$name}_flag");
if(is_numeric($time) && time() - $time > 1){//如果循環等待時間大於1秒,則不再等待。
break;
}
}
$id = $redis->incr("sequence_{$name}");
//如果操作失敗,則從sequence表中獲取全局id並加載到redis
if (intval($id) === 1 or $id === false) {
$last_id = $seq_dao->get_seq_id($name);//從數據庫獲取全局id
if(!is_numeric($last_id)){
throw new Exception("fail to get id from db");
}
$ret = $redis->set("sequence_{$name}",$last_id);
if($ret == false){
throw new Exception("fail to set redis key [ sequence_{$name} ]");
}
$id = $redis->incr("sequence_{$name}");
if(!is_numeric($id)){
throw new Exception("fail to incr redis key [ sequence_{$name} ]");
}
}
$seq_dao->set_seq_id($name, $id);//把生成的全局id寫入數據表sequence
$redis->delete("sequence_{$name}_flag");//刪除key,相當於釋放鎖
$db = null;
return $id;
}
3、redis和db結合
使用redis直接操作內存,可能性能會好些。但是如果redis死掉後,如何處理呢?把以上兩種方案結合,提供更好的穩定性。
代碼如下:
function next_id($name){
try{
return $this->next_id_redis($name);
}
catch(Exception $e){
return $this->next_id_db($name);
}
}
4、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實例,有些浪費資源,成本較高。
以上內容是小編給大家分享的Mysql全局ID生成方法,希望大家喜歡。