在开发中有些敏感接口,例如用户余额提现接口,需要考虑在并发情况下接口是否会发生问题。如果用户将自己的多条提现请求同时发送到服务器,代码能否扛得住呢?一旦没做锁,那么就真的会给用户多次提现,给公司带来损失。我来简单介绍一下在这种接口开发过程中,我的做法。
第一阶段:
我们使用的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 = ", 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 = ", 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 = ", 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 = ", 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 = ", 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 = ", 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测试,嗯,锁成功了只有,只提现了一次,大功告成~
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新动态
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]