這篇文章給大家分享的是有關(guān)go利用orm實(shí)現(xiàn)接口分布式鎖的方法的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

下城網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),下城網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為下城上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的下城做網(wǎng)站的公司定做！

第一階段:

我們使用的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 = 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ā)問(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 = 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è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)了一次，大功告成～

感謝各位的閱讀！關(guān)于“go利用orm實(shí)現(xiàn)接口分布式鎖的方法”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！