go 利用orm簡單實現接口分佈式鎖

在開發中有些敏感接口，例如用戶餘額提現接口，須要考慮在併發狀況下接口是否會發生問題。若是用戶將本身的多條提現請求同時發送到服務器，代碼可否扛得住呢？一旦沒作鎖，那麼就真的會給用戶屢次提現，給公司帶來損失。我來簡單介紹一下在這種接口開發過程當中，個人作法。

 

第一階段:

咱們使用的orm爲xorm，提現表對應的結構體以下

type Participating struct {
	ID      uint          `xorm:"autoincr id" json:"id,omitempty"`
	Openid  string        `xorm:"openid" json:"openid"`
	Hit     uint          `xorm:"hit" json:"hit"`
	Orderid string        `xorm:"order_id" json:"order_id"`
	Redpack uint          `xorm:"redpack" json:"redpack"`
	Status  uint          `xorm:"status" json:"status"`
	Ctime   tool.JsonTime `xorm:"ctime" json:"ctime,omitempty"`
	Utime   tool.JsonTime `xorm:"utime" json:"utime,omitempty"`
	PayTime tool.JsonTime `xorm:"pay_time" json:"pay_time,omitempty"`
}

在Participating表中，是以Openid去重的，當一個Openid對應的Hit爲1時，能夠按照Redpack的數額提現，成功後將Status改成1，簡單來講這就是提現接口的業務邏輯。

起初我並無太在乎併發的問題，我在MySQL的提現表中設置一個字段status來記錄提現狀態，我只是在提現時將狀態修改成2(體現中)，提現完成後將status修改成1(已提現)。而後事實證實，我太天真了，用ab作了測試1s發送了1000個請求到服務器，結果。。。成功提現了6次。部分代碼以下

p_info := &Participating{}
// 查找具體提現數額
has, _ := db.Dalmore.Where("openid = ? and hit = 1 and status = 0", openid).Get(p_info)
if !has {
	resp.Error(errcode.NO_REDPACK_FOUND, nil, nil)
	return
}

// 改status爲提現中
p_info.Status = 2
db.Dalmore.Cols("status").Where("openid = ? and hit = 1 and status = 0", openid).Update(p_info)

// 提現p_info.Redpack

 

第二階段：

既然出現了併發問題，那第一反應確定的加鎖啊，代碼以下：

type Set struct {
	m map[string]bool
	sync.RWMutex
}

func New() *Set {
	return &Set{
		m: map[string]bool{},
	}
}

var nodelock = set.New()

// 加鎖
nodelock.Lock()

p_info := &Participating{}
// 查找具體提現數額
has, _ := db.Dalmore.Where("openid = ? and hit = 1 and status = 0", openid).Get(p_info)
if !has {
	resp.Error(errcode.NO_REDPACK_FOUND, nil, nil)
	return
}

// 改status爲提現中
p_info.Status = 2
db.Dalmore.Cols("status").Where("openid = ? and hit = 1 and status = 0", openid).Update(p_info)

// 釋放鎖
nodelock.Unlock()

// 提現p_info.Redpack

　　

加了鎖之後。。。emem，容許屢次提現的問題解決了，可是這個鎖限制的範圍太多了，直接讓這段加鎖代碼變成串行，這大大下降了接口性能。並且，一旦部署多個服務端，這個鎖又會出現屢次提現的問題，由於他只能攔住這一個服務的併發。看來得搞一個不影響性能的分佈式纔是王道啊。

 

第三階段：

利用redis，設置一個key爲openid的分佈式鎖，並設置一個過時時間能夠解決當前的這個問題。可是難道就沒別的辦法了嗎？固然是有的，golang的xorm中Update函數實際上是有返回值的：num,err，我就是利用num作了個分佈式鎖。

//記錄update修改條數
num, err := db.Dalmore.Cols("status").Where("openid = ? and status = 0 and hit = 1", openid).Update(p_update)
if err != nil {
	logger.Runtime().Debug(map[string]interface{}{"error": err.Error()}, "error while updating")
	resp.Error(errcode.INTERNAL_ERROR, nil, nil)
	return
}

// 查看update操做到底修改了多少條數據，起到了分佈式鎖的做用
if num != 1 {
	resp.Error(errcode.NO_REDPACK_FOUND, nil, nil)
	return
}

p_info := &Participating{}
_, err := db.Dalmore.Where("openid = ? and status = 2", openid).Get(p_info)
if err != nil {
	logger.Runtime().Debug(map[string]interface{}{"error": err.Error()}, "error while selecting")
	resp.Error(errcode.INTERNAL_ERROR, nil, nil)
	return
}

// 提現p_info.Redpack

　　

其實有點投機取巧的意思，利用xorm的Update函數，咱們將覈對併發處理請求下數據準確性的問題拋給了MySQL，畢竟MySQL是通過千錘百煉的。再用ab測試，嗯，鎖成功了只有，只提現了一次，大功告成～

但願對你們有所幫助，祝你們天天開心～