在開(kāi)發(fā)中有些敏感接口，例如用戶(hù)余額提現(xiàn)接口，需要考慮在并發(fā)情況下接口是否會(huì)發(fā)生問(wèn)題。如果用戶(hù)將自己的多條提現(xiàn)請(qǐng)求同時(shí)發(fā)送到服務(wù)器，代碼能否扛得住呢？一旦沒(méi)做鎖，那么就真的會(huì)給用戶(hù)多次提現(xiàn)，給公司帶來(lái)?yè)p失。我來(lái)簡(jiǎn)單介紹一下在這種接口開(kāi)發(fā)過(guò)程中，我的做法。
第一階段:
我們使用的orm為xorm，提現(xiàn)表對(duì)應(yīng)的結(jié)構(gòu)體如下
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)一個(gè)Openid對(duì)應(yīng)的Hit為1時(shí)，可以按照Redpack的數(shù)額提現(xiàn)，成功后將Status改為1，簡(jiǎn)單來(lái)說(shuō)這就是提現(xiàn)接口的業(yè)務(wù)邏輯。
起初我并沒(méi)有太在意并發(fā)的問(wèn)題，我在MySQL的提現(xiàn)表中設(shè)置一個(gè)字段status來(lái)記錄提現(xiàn)狀態(tài)，我只是在提現(xiàn)時(shí)將狀態(tài)修改為2(體現(xiàn)中)，提現(xiàn)完成后將status修改為1(已提現(xiàn))。然后事實(shí)證明，我太天真了，用ab做了測(cè)試1s發(fā)送了1000個(gè)請(qǐng)求到服務(wù)器，結(jié)果。。。成功提現(xiàn)了6次。部分代碼如下
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 = 2db.Dalmore.Cols("status").Where("openid = ? and hit = 1 and status = 0", openid).Update(p_info)// 提現(xiàn)p_info.Redpack第二階段：
既然出現(xiàn)了并發(fā)問(wèn)題，那第一反應(yīng)肯定的加鎖啊，代碼如下：
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 = 2db.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èn)題解決了，但是這個(gè)鎖限制的范圍太多了，直接讓這段加鎖代碼變成串行，這大大降低了接口性能。而且，一旦部署多個(gè)服務(wù)端，這個(gè)鎖又會(huì)出現(xiàn)多次提現(xiàn)的問(wèn)題，因?yàn)樗荒軘r住這一個(gè)服務(wù)的并發(fā)。看來(lái)得搞一個(gè)不影響性能的分布式才是王道啊。
第三階段：
利用redis，設(shè)置一個(gè)key為openid的分布式鎖，并設(shè)置一個(gè)過(guò)期時(shí)間可以解決當(dāng)前的這個(gè)問(wèn)題。但是難道就沒(méi)別的辦法了嗎？當(dāng)然是有的，golang的xorm中Update函數(shù)其實(shí)是有返回值的：num,err，我就是利用num做了個(gè)分布式鎖。
//記錄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其實(shí)有點(diǎn)投機(jī)取巧的意思，利用xorm的Update函數(shù)，我們將核對(duì)并發(fā)處理請(qǐng)求下數(shù)據(jù)準(zhǔn)確性的問(wèn)題拋給了MySQL，畢竟MySQL是經(jīng)過(guò)千錘百煉的。再用ab測(cè)試，嗯，鎖成功了只有，只提現(xiàn)了一次，大功告成～
以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持VEVB武林網(wǎng)。
新聞熱點(diǎn)
疑難解答
圖片精選
網(wǎng)友關(guān)注
