生產系統隨著業務增長總會經歷一個業務量由小變大的過程,可擴展性是考量數據庫系統高可用性的一個重要指標;在單表/數據庫數據量過大,更新量不斷飙漲時,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生成方法,希望大家喜歡。