您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關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測試,嗯,鎖成功了只有,只提現了一次,大功告成~
感謝各位的閱讀!關于“go利用orm實現接口分布式鎖的方法”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。