淺談CAS在分布式id生成方案上的應(yīng)用

作者：58沈劍 2017-06-19 17:55:22

開發(fā)

開發(fā)工具

分布式 所謂“分布式ID生成方案”，是指在分布式環(huán)境下，生成全局唯一ID的方法。本文介紹了CAS在分布式ID生成方案上的一種應(yīng)用

創(chuàng)新互聯(lián)公司主要從事網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)吳興,10多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

今天還是聊CAS，談?wù)凜AS在一種“分布式ID生成方案”上的應(yīng)用。

所謂“分布式ID生成方案”，是指在分布式環(huán)境下，生成全局唯一ID的方法。

可以利用DB自增鍵(auto inc id)來生成全局唯一ID，插入一條記錄，生成一個(gè)ID：

這個(gè)方案利用了數(shù)據(jù)庫的單點(diǎn)特性，其優(yōu)點(diǎn)為：

• 無需寫額外代碼
• 全局唯一
• 絕對遞增
• 遞增ID的步長確定

其不足為：

• 需要做數(shù)據(jù)庫HA，保證生成ID的高可用
• 數(shù)據(jù)庫中記錄數(shù)較多
• 生成ID的性能，取決于數(shù)據(jù)庫插入性能

優(yōu)化方案為：

• 利用雙主保證高可用
• 定期刪除數(shù)據(jù)
• 增加一層服務(wù)，采用批量生成的方式降低數(shù)據(jù)庫的寫壓力，提升整體性能

增加服務(wù)后，DB中只需保存當(dāng)前***的ID即可，在服務(wù)啟動(dòng)初始化的過程中，首先拉取當(dāng)前的max-id：

  
 
 
 

   
  
  
  
select max_id from T; 
  
 
 
 

然后批量獲取一批ID，放到id-servcie內(nèi)存里，并將max-id寫回?cái)?shù)據(jù)庫：

  
 
 
 

   
  
  
  
update T set max_id=200; 
  
 
 
 

這樣，id-service就拿到了[100, 200]這一批ID，上游在獲取ID時(shí)，不用每次都插入數(shù)據(jù)庫，而是分配完100個(gè)ID后，再修改max-id的值，這樣分配ID的整體性能就增加了100倍。

這個(gè)方案的優(yōu)點(diǎn)：

• 數(shù)據(jù)庫只保存一條記錄
• 性能極大增強(qiáng)

其不足為：

• 如果id-service重啟，可能內(nèi)存會(huì)有一段已經(jīng)申請的ID沒有分配出去，導(dǎo)致ID空洞，當(dāng)然，這不是一個(gè)嚴(yán)重的問題
• 服務(wù)沒有做HA，無法保證高可用

優(yōu)化方案為：

• 冗余服務(wù)，做集群保證高可用

冗余了服務(wù)后，多個(gè)服務(wù)在啟動(dòng)過程中，進(jìn)行ID批量申請時(shí)，可能由于并發(fā)導(dǎo)致數(shù)據(jù)不一致：

  
 
 
 

   
  
  
  
select max_id from T; 
  
 
 
 

如上圖所示，兩個(gè)id-service在啟動(dòng)的過程中，同時(shí)拿到了max-id為100。

兩個(gè)id-service同時(shí)對數(shù)據(jù)庫的max-id進(jìn)行寫回：

  
 
 
 

   
  
  
  
update T set max_id=200; 
  
 
 
 

寫回max-id成功后，這兩個(gè)id-service都以為自己拿到了[100,200]這一批ID，導(dǎo)致集群會(huì)生成重復(fù)的ID。

問題發(fā)生的原因，是并發(fā)寫回時(shí)，沒有對max-id的初始值進(jìn)行比對：

• id-service1寫回max-id=200成功的條件是，max-id必須等于100
• id-service2寫回max-id=200成功的條件是，max-id也必須等于100
• id-service1寫回時(shí)，max-id是100，理應(yīng)寫回成功
• id-service2寫回時(shí)，max-id已經(jīng)被改成了200，不應(yīng)該寫回成功

只要實(shí)施CAS樂觀鎖，在寫回時(shí)對max-id的初始條件進(jìn)行比對，就能避免數(shù)據(jù)的不一致，寫回SQL由：

  
 
 
 

   
  
  
  
update T set max_id=200; 
  
 
 
 

升級(jí)為：

  
 
 
 

   
  
  
  
update T set max_id=200 where max_id=100; 
  
 
 
 

這樣，id-service2寫回時(shí)，就會(huì)失?。?/p>

失敗后，id-service2要再次查詢max-id：

此時(shí)max-id已經(jīng)變?yōu)?00，于是id-service2獲取到了[200, 300]這一批ID，并將max-id=300寫回：

  
 
 
 

   
  
  
  
update t set max_id=300 where max_id=200; 
  
 
 
 

寫回成功。

這種方案的好處是：

• 能夠通過水平擴(kuò)展的方式，達(dá)到分布式ID生成服務(wù)的***性能
• 使用CAS簡潔的保證不會(huì)生成重復(fù)的ID

其不足為：

• 由于有多個(gè)service，生成的ID 不是絕對遞增的，而是趨勢遞增的

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文

文章題目：淺談CAS在分布式ID生成方案上的應(yīng)用
URL標(biāo)題：http://m.5511xx.com/article/cdphpjg.html