|
在開發(fā)中有些敏感接口，例如用戶余額提現(xiàn)接口，需要考慮在并發(fā)情況下接口是否會發(fā)生問題。如果用戶將自己的多條提現(xiàn)請求同時發(fā)送到服務(wù)器，代碼能否扛得住呢？一旦沒做鎖，那么就真的會給用戶多次提現(xiàn)，給公司帶來損失。我來簡單介紹一下在這種接口開發(fā)過程中，我的做法。 第一階段: 我們使用的orm為xorm，提現(xiàn)表對應(yīng)的結(jié)構(gòu)體如下 1 2 3 4 5 6 7 8 9 10 11 | 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表中，是以O(shè)penid去重的，當(dāng)一個Openid對應(yīng)的Hit為1時，可以按照Redpack的數(shù)額提現(xiàn)，成功后將Status改為1，簡單來說這就是提現(xiàn)接口的業(yè)務(wù)邏輯。 起初我并沒有太在意并發(fā)的問題，我在MySQL的提現(xiàn)表中設(shè)置一個字段status來記錄提現(xiàn)狀態(tài)，我只是在提現(xiàn)時將狀態(tài)修改為2(體現(xiàn)中)，提現(xiàn)完成后將status修改為1(已提現(xiàn))。然后事實證明，我太天真了，用ab做了測試1s發(fā)送了1000個請求到服務(wù)器，結(jié)果。。。成功提現(xiàn)了6次。部分代碼如下 1 2 3 4 5 6 7 8 9 10 11 12 | p_info := &Participating{}<br>// 查找具體提現(xiàn)數(shù)額
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為提現(xiàn)中
p_info.Status = 2
db.Dalmore.Cols('status').Where('openid = ? and hit = 1 and status = 0', openid).Update(p_info)
// 提現(xiàn)p_info.Redpack
|
第二階段： 既然出現(xiàn)了并發(fā)問題，那第一反應(yīng)肯定的加鎖啊，代碼如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | 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{}
// 查找具體提現(xiàn)數(shù)額
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為提現(xiàn)中
p_info.Status = 2
db.Dalmore.Cols('status').Where('openid = ? and hit = 1 and status = 0', openid).Update(p_info)
// 釋放鎖
nodelock.Unlock()
// 提現(xiàn)p_info.Redpack
|
加了鎖以后。。。emem，允許多次提現(xiàn)的問題解決了，但是這個鎖限制的范圍太多了，直接讓這段加鎖代碼變成串行，這大大降低了接口性能。而且，一旦部署多個服務(wù)端，這個鎖又會出現(xiàn)多次提現(xiàn)的問題，因為他只能攔住這一個服務(wù)的并發(fā)。看來得搞一個不影響性能的分布式才是王道啊。 第三階段： 利用redis，設(shè)置一個key為openid的分布式鎖，并設(shè)置一個過期時間可以解決當(dāng)前的這個問題。但是難道就沒別的辦法了嗎？當(dāng)然是有的，golang的xorm中Update函數(shù)其實是有返回值的：num,err，我就是利用num做了個分布式鎖。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | //記錄update修改條數(shù)
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操作到底修改了多少條數(shù)據(jù)，起到了分布式鎖的作用
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
}
// 提現(xiàn)p_info.Redpack
|
其實有點投機取巧的意思，利用xorm的Update函數(shù)，我們將核對并發(fā)處理請求下數(shù)據(jù)準(zhǔn)確性的問題拋給了MySQL，畢竟MySQL是經(jīng)過千錘百煉的。再用ab測試，嗯，鎖成功了只有，只提現(xiàn)了一次，大功告成～ 希望對大家有所幫助，祝大家每天開心～
|
