随着618的临近,各种促销活动开始变得热门起来,比较主流的有秒杀、抢优惠券、拼团等等。涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券。

本文内容

  • 使用Redis优化高并发场景下的接口性能
  • 数据库乐观锁

前提

活动规则

  • 奖品数量有限,比如100个
  • 不限制参与用户数
  • 每个用户只能参与1次秒杀

活动要求

  • 不能多发,也不能少发,100个奖品要全部发出去
  • 1个用户最多抢1个奖品
  • 遵循先到先得原则,先来的用户有奖品

数据库实现

悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点。

数据库结构

  • 未中奖时UserId为0,RewardAt为NULL
  • 中奖时UserId为中奖用户ID,RewardAt为中奖时间

乐观锁实现

乐观锁实际上并不存在真正的锁,乐观锁是利用数据的某个字段来做的,比如本文的例子就是以UserId来实现的。

实现流程如下:

1.查询UserId为0的奖品,如果未找到则提示无奖品

SELECT * FROM envelope WHERE user_id=0 LIMIT 1 

2.更新奖品的用户ID和中奖时间(假设奖品ID为1,中奖用户ID为100,当前时间为2019-10-29 12:00:00),这里的user_id=0就是我们的乐观锁了。

UPDATE envelope SET user_id=100, reward_at='2019-10-29 12:00:00' WHERE user_id=0 AND id=1 

3.检测UPDATE语句的执行返回值,如果返回1证明中奖成功,否则证明该奖品被其他人抢了

为什么要添加乐观锁

正常情况下获取奖品、然后把奖品更新给指定用户是没问题的。如果不添加user_id=0时,高并发场景下会出现下面的问题:

  1. 两个用户同时查询到了1个未中奖的奖品(发生并发问题)
  2. 将奖品的中奖用户更新为用户1,更新条件只有ID=奖品ID
  3. 上述SQL执行是成功的,影响行数也是1,此时接口会返回用户1中奖
  4. 接下来将中奖用户更新为用户2,更新条件也只有ID=奖品ID
  5. 由于是同一个奖品,已经发给用户1的奖品会重新发放给用户2,此时影响行数为1,接口返回用户2也中奖
  6. 所以该奖品的最终结果是发放给用户2
  7. 用户1就会过来投诉活动方了,因为抽奖接口返回用户1中奖,但他的奖品被抢了,此时活动方只能赔钱了

添加乐观锁之后的抽奖流程

  1. 更新用户1时的条件为id=红包ID AND user_id=0 ,由于此时红包未分配给任何人,用户1更新成功,接口返回用户1中奖
  2. 当更新用户2时更新条件为id=红包ID AND user_id=0,由于此时该红包已经分配给用户1了,所以该条件不会更新任何记录,接口返回用户2中奖

乐观锁优缺点

优点

  • 性能尚可,因为无锁
  • 不会超发

缺点

  • 通常不满足“先到先得”的活动规则,一旦发生并发,就会发生未中奖的情况,此时奖品库还有奖品

压测

在MacBook Pro 2018上的压测表现如下(Golang实现的HTTP服务器,MySQL连接池大小100,Jmeter压测):

  • 500并发 500总请求数 平均响应时间331ms 发放成功数为31 吞吐量458.7/s

Redis实现

可以看到乐观锁的实现下争抢比太高,不是推荐的实现方法,下面通过Redis来优化这个秒杀业务。

Redis高性能的原因

  • 单线程 省去了线程切换开销
  • 基于内存的操作 虽然持久化操作涉及到硬盘访问,但是那是异步的,不会影响Redis的业务
  • 使用了IO多路复用

实现流程

1.活动开始前将数据库中奖品的code写入Redis队列中

2.活动进行时使用lpop弹出队列中的元素

3.如果获取成功,则使用UPDATE语法发放奖品

UPDATE reward SET user_id=用户ID,reward_at=当前时间 WHERE code='奖品码' 

4.如果获取失败,则当前无可用奖品,提示未中奖即可

使用Redis的情况下并发访问是通过Redis的lpop()来保证的,该方法是原子方法,可以保证并发情况下也是一个个弹出的。

压测

在MacBook Pro 2018上的压测表现如下(Golang实现的HTTP服务器,MySQL连接池大小100,Redis连接池代销100,Jmeter压测):

  • 500并发 500总请求数 平均响应时间48ms 发放成功数100 吞吐量497.0/s

结论

可以看到Redis的表现是稳定的,不会出现超发,且访问延迟少了8倍左右,吞吐量还没达到瓶颈,可以看出Redis对于高并发系统的性能提升是非常大的!接入成本也不算高,值得学习!

实验代码

// main.go
package main import ( "fmt" "github.com/go-redis/redis" _ "github.com/go-sql-driver/mysql" "github.com/jinzhu/gorm" "log" "net/http" "strconv" "time"
) type Envelope struct { Id        int `gorm:"primary_key"` Code      string UserId    int CreatedAt time.Time RewardAt  *time.Time
} func (Envelope) TableName() string { return "envelope"
} func (p *Envelope) BeforeCreate() error { p.CreatedAt = time.Now() return nil
} const ( QueueEnvelope = "envelope" QueueUser     = "user"
) var ( db          *gorm.DB redisClient *redis.Client
) func init() { var err error db, err = gorm.Open("mysql", "root:root@tcp(localhost:3306)/test?charset=utf8&parseTime=True&loc=Local") if err != nil { log.Fatal(err) } if err = db.DB().Ping(); err != nil { log.Fatal(err) } db.DB().SetMaxOpenConns(100) fmt.Println("database connected. pool size 10")
} func init() { redisClient = redis.NewClient(&redis.Options{ Addr:     "localhost:6379", DB:       0, PoolSize: 100, }) if _, err := redisClient.Ping().Result(); err != nil { log.Fatal(err) } fmt.Println("redis connected. pool size 100")
} // 读取Code写入Queue
func init() { envelopes := make([]Envelope, 0, 100) if err := db.Debug().Where("user_id=0").Limit(100).Find(&envelopes).Error; err != nil { log.Fatal(err) } if len(envelopes) != 100 { log.Fatal("不足100个奖品") } for i := range envelopes { if err := redisClient.LPush(QueueEnvelope, envelopes[i].Code).Err(); err != nil { log.Fatal(err) } } fmt.Println("load 100 envelopes")
} func main() { http.HandleFunc("/envelope", func(w http.ResponseWriter, r *http.Request) { uid := r.Header.Get("x-user-id") if uid == "" { w.WriteHeader(401) _, _ = fmt.Fprint(w, "UnAuthorized") return } uidValue, err := strconv.Atoi(uid) if err != nil { w.WriteHeader(400) _, _ = fmt.Fprint(w, "Bad Request") return } // 检测用户是否抢过了 if result, err := redisClient.HIncrBy(QueueUser, uid, 1).Result(); err != nil || result != 1 { w.WriteHeader(429) _, _ = fmt.Fprint(w, "Too Many Request") return } // 检测是否在队列中 code, err := redisClient.LPop(QueueEnvelope).Result() if err != nil { w.WriteHeader(200) _, _ = fmt.Fprint(w, "No Envelope") return } // 发放红包 envelope := &Envelope{} err = db.Where("code=?", code).Take(&envelope).Error if err == gorm.ErrRecordNotFound { w.WriteHeader(200) _, _ = fmt.Fprint(w, "No Envelope") return } if err != nil { w.WriteHeader(500) _, _ = fmt.Fprint(w, err) return } now := time.Now() envelope.UserId = uidValue envelope.RewardAt = &now rowsAffected := db.Where("user_id=0").Save(&envelope).RowsAffected // 添加user_id=0来验证Redis是否真的解决争抢问题 if rowsAffected == 0 { fmt.Printf("发生争抢. id=%dn", envelope.Id) w.WriteHeader(500) _, _ = fmt.Fprintf(w, "发生争抢. id=%dn", envelope.Id) return } _, _ = fmt.Fprint(w, envelope.Code) }) fmt.Println("listen on 8080") fmt.Println(http.ListenAndServe(":8080", nil))
} 

以上有不足的地方可以指出讨论,觉得不错的朋友希望能得到您的转发支持,同时可以持续关注我,每天分享Linux C/C++后台开发干货内容!

后台私信《Linux》获取C++/Linux后台开发高级进阶视频资料。

go http 并发数限制_618临近,Redis优化高并发下的抢枪抢买买买性能相关推荐

  1. redis抽奖并发_Redis优化高并发下的秒杀性能

    本文内容 使用Redis优化高并发场景下的接口性能 数据库乐观锁 随着双11的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等. 涉及到高并发争抢同一个资源的主要场景有秒杀和抢 ...

  2. php post发微博,php结合redis实现高并发下发帖、发微博的方法

    本篇文章主要介绍php结合redis实现高并发下发帖.发微博的方法,感兴趣的朋友参考下,希望对大家有所帮助. 发帖.发微博.点赞.评论等这些操作很频繁的动作如果并发量小,直接入库是最简单的 但是并发量 ...

  3. 测试nignx php请求并发数,Nginx 高级篇(八)ab 压力测试即 nginx 的性能统计模块...

    我们总得要对自己的网站或者接口做压力测试的,总不能写好了代码不做测试就上线啊,谁知道你的网站或者接口能承受多少的并发和访问量,压力测试我们可以使用apache的ab小工具来搞或者使用github上提供 ...

  4. 简单实现redis实现高并发下的抢购/秒杀功能

    简述 抢购/秒杀是如今很常见的一个应用场景,那么高并发竞争下如何解决超抢(或超卖库存不足为负数的问题)呢? 常规写法: 查询出对应商品的库存,看是否大于0,然后执行生成订单等操作,但是在判断库存是否大 ...

  5. java redis实现抢购_【抢购/秒杀】redis实现高并发下的抢购/秒杀功能

    问题: 抢购/秒杀是如今很常见的一个应用场景,那么高并发竞争下如何解决超抢(或超卖库存不足为负数的问题)呢? 常规写法: 查询出对应商品的库存,看是否大于0,然后执行生成订单等操作,但是在判断库存是否 ...

  6. java 抽奖 高并发_【java】如何设计高并发下的抽奖?

    我写的伪代码如下,但出现了个bug,抽奖现在要限制每日抽奖结果出现的次数,但实际运行是在并发时不能限制住,如何解决? resultDayLimitTimes = { resultA => 2 # ...

  7. PHP redis秒杀返回结果,php结合redis实现高并发下的抢购、秒杀功能

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个: 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少("超卖"问题) 对于第一个问题,已经很容易想到 ...

  8. php结合redis实现高并发下的抢购、秒杀功能

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个: 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少("超卖"问题) 对于第一个问题,已经很容易想到 ...

  9. PHP 结合redis实现高并发下抢购、秒杀

    抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个: 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少("超卖"问题) 对于第一个问题,已经很容易想到 ...

最新文章

  1. 基于FPGA的IP核RAM的设计和调用
  2. 算法提高课-数学知识-矩阵乘法-AcWing 1303. 斐波那契前 n 项和:矩阵乘法,快速幂,线性代数
  3. CentOS7通过yum安装MySQL5.7
  4. mybatis一套完整入门教程
  5. lc滤波电路电感电容值选择_电感器变压器选型与应用
  6. oracle安装检测空间china,oracle安装 - Ginn的个人空间 - OSCHINA - 中文开源技术交流社区...
  7. 经典面试题:Integer c=100,d=100,c==d 一定是false吗?
  8. LeetCode(1021)——删除最外层的括号(JavaScript)
  9. php smarty ci,CI整合Smarty,cismarty_PHP教程
  10. 用python做频数分析_如何用Python制作频率(频数)分布表(图)?
  11. Mac 快捷键 桌面壁纸
  12. 07 -MATLAB数值微积分与方程求解
  13. mapabc高德地图区域收缩事件监听
  14. 高通APQ8009w LTR303_ALS 光感(sensor)兼容模式调试
  15. 什么是单页网站设计?受欢迎的原因在哪?
  16. Win11 连接不上NAS
  17. python获取文件夹大小_S3 API for python–创建bucket文件夹统计文件夹大小
  18. 如何群发电子邮件?群发邮箱账号批发吗?
  19. Python错误集锦:matplotlib legend提示:ValueError: Unrecognized location ‘upper’. Valid locations are
  20. Wireshark malformed packet

热门文章

  1. tesseract-orc 合并识别结果
  2. 策略模式(headfirst设计模式学习笔记)
  3. Animator忽视TimeScale
  4. Word 模板 - 新建向导
  5. 科普:为什么 String hashCode 方法选择数字31作为乘子
  6. springMVC之mvc:interceptors拦截器的用法
  7. windows安装安卓开发环境Eclipse+SDK+ADT
  8. ibatis动态的传入表名、字段名
  9. Hadoop Namenode不能启动
  10. Java 设计模式之普通代理