Redis优化高并发下的秒杀性能(redis的优化操作)
mhr18 2024-11-08 12:14 46 浏览 0 评论
- 使用Redis优化高并发场景下的接口性能
- 数据库乐观锁
随着双11的临近,各种促销活动开始变得热门起来,比较主流的有秒杀、抢优惠券、拼团等等。
涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券。
前提
活动规则
- 奖品数量有限,比如100个
- 不限制参与用户数
- 每个用户只能参与1次秒杀
活动要求
- 不能多发,也不能少发,100个奖品要全部发出去
- 1个用户最多抢1个奖品
- 遵循先到先得原则,先来的用户有奖品
数据库实现
悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点。
数据库结构
IDCodeUserIdCreatedAtRewardAt奖品ID奖品码用户ID创建时间中奖时间
- 未中奖时UserId为0,RewardAt为NULL
- 中奖时UserId为中奖用户ID,RewardAt为中奖时间
乐观锁实现
乐观锁实际上并不存在真正的锁,乐观锁是利用数据的某个字段来做的,比如本文的例子就是以UserId来实现的。
实现流程如下:
- 查询UserId为0的奖品,如果未找到则提示无奖品
SELECT * FROM envelope WHERE user_id=0 LIMIT 1
- 更新奖品的用户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
- 检测UPDATE语句的执行返回值,如果返回1证明中奖成功,否则证明该奖品被其他人抢了
为什么要添加乐观锁
正常情况下获取奖品、然后把奖品更新给指定用户是没问题的。如果不添加user_id=0时,高并发场景下会出现下面的问题:
用户1就会过来投诉活动方了,因为抽奖接口返回用户1中奖,但他的奖品被抢了,此时活动方只能赔钱了
添加乐观锁之后的抽奖流程
id=红包ID AND user_id=0 id=红包ID AND user_id=0
乐观锁优缺点
优点
- 性能尚可,因为无锁
- 不会超发
缺点
- 通常不满足“先到先得”的活动规则,一旦发生并发,就会发生未中奖的情况,此时奖品库还有奖品
压测
在MacBook Pro 2018上的压测表现如下(Golang实现的HTTP服务器,MySQL连接池大小100,Jmeter压测):
- 500并发 500总请求数 平均响应时间331ms 发放成功数为31 吞吐量458.7/s
Redis实现
可以看到乐观锁的实现下争抢比太高,不是推荐的实现方法,下面通过Redis来优化这个秒杀业务。
Redis高性能的原因
- 单线程 省去了线程切换开销
- 基于内存的操作 虽然持久化操作涉及到硬盘访问,但是那是异步的,不会影响Redis的业务
- 使用了IO多路复用
实现流程
- 活动开始前将数据库中奖品的code写入Redis队列中
- 活动进行时使用lpop弹出队列中的元素
- 如果获取成功,则使用UPDATE语法发放奖品
UPDATE reward SET user_id=用户ID,reward_at=当前时间 WHERE code='奖品码'
- 如果获取失败,则当前无可用奖品,提示未中奖即可
使用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=%d\n", envelope.Id) w.WriteHeader(500) _, _ = fmt.Fprintf(w, "发生争抢. id=%d\n", envelope.Id) return } _, _ = fmt.Fprint(w, envelope.Code) }) fmt.Println("listen on 8080") fmt.Println(http.ListenAndServe(":8080", nil)) }
相关推荐
- Redis教程——数据类型(字符串、列表)
-
上篇文章我们学习了Redis教程——Redis入门,这篇文章我们学习Redis教程——数据类型(字符串、列表)。Redis数据类型有:字符串、列表、哈希表、集合、有序集合、地理空间、基数统计、位图、位...
- 说说Redis的数据类型(redis数据类型详解)
-
一句话总结Redis核心数据类型包括:String:存储文本、数字或二进制数据。List:双向链表,支持队列和栈操作。Hash:字段-值映射,适合存储对象。Set:无序唯一集合,支持交并差运算。Sor...
- Redis主从复制(Redis主从复制复制文件)
-
介绍Redis有两种不同的持久化方式,Redis服务器通过持久化,把Redis内存中持久化到硬盘当中,当Redis宕机时,我们重启Redis服务器时,可以由RDB文件或AOF文件恢复内存中的数据。不过...
- 深入解析 Redis 集群的主从复制实现方式
-
在互联网大厂的后端开发领域,Redis作为一款高性能的内存数据库,被广泛应用于缓存、消息队列等场景。而Redis集群中的主从复制机制,更是保障数据安全、实现读写分离以及提升系统性能的关键所在。今...
- Redis + MQ:高并发秒杀的技术方案与实现
-
大家好,我是一安~前言在电商秒杀场景中,瞬间爆发的海量请求往往成为系统的生死考验。当并发量达到数万甚至数十万QPS时,传统数据库单表架构难以支撑,而Redis与消息队...
- Redis面试题2025(redis面试题及答案2024)
-
Redis基础什么是Redis?它的主要特点是什么?Redis和Memcached有什么区别?Redis支持哪些数据类型?Redis的字符串类型最大能存储多少数据?Redis的列表类型和集合类型有什么...
- Redis学习笔记:过期键管理与EXPIRE命令详解(第七章)
-
在Redis中,过期键(ExpireKey)机制是实现缓存自动失效、临时数据管理的核心功能。EXPIRE命令作为设置键过期时间的基础工具,其工作原理与使用细节直接影响系统的内存效率和数据一致性。本章...
- Redis传送术:几分钟内将生产数据迁移到本地
-
在生产环境中使用Redis就像一把双刃剑。它快速、强大,存储了大量实时数据——但当你想要在本地调试问题或使用真实数据进行测试时,事情就变得棘手了。我们要做什么?我们想要从生产环境Redis实例中导出键...
- 使用redis bitmap计算日活跃用户数
-
Metrics(指标)在允许延迟的情况下,通常通过job任务定时执行(如按小时、每天等频率),而基于Redis的Bitmap使我们能够实时完成此类计算,且极其节省空间。以亿级用户计算“日活跃用户...
- 大部分.NET开发者都不知道的Redis性能优化神技!
-
你还在为Redis存储空间不够而发愁吗?还在为Json数据太大导致网络传输缓慢而头疼吗?今天我要告诉你一个让Redis性能飙升300%的秘密武器!这个技巧简单到让你怀疑人生,但效果却强大到让你的老板对...
- Redis学习笔记:内存优化实战指南(第六章)
-
Redis作为内存数据库,内存使用效率直接影响系统性能与成本。对于处理大规模数据的场景,合理的内存优化能显著降低资源消耗,提升服务稳定性。本章将基于Redis的内存管理特性,详解实用的优化技巧与最佳实...
- 大数据-47 Redis 内存控制、Key 过期与数据...
-
点一下关注吧!!!非常感谢!!持续更新!!!AI篇持续更新中!(长期更新)AI炼丹日志-30-新发布【1T万亿】参数量大模型!Kimi-K2开源大模型解读与实践,持续打造实用AI工具指南!...
- Redis学习笔记:内存优化进阶与实战技巧(第六章·续)
-
上一节我们介绍了Redis内存优化的基础策略,本节将深入更多实战技巧,包括数据结构的精细化选择、过期键的内存回收机制,以及大规模场景下的内存管理方案,帮助你在高并发场景下进一步提升内存利用率。七、数据...
- 低配服务器(2核3G)宝塔面板的Redis优化指南:512MB内存高效运行
-
在2核3G内存的低配服务器上部署Redis服务时,资源分配不当极易导致服务器崩溃。本文针对宝塔面板环境(PHP8.2+MariaDB10.6+Nginx),提供经过实战验证的Redis优化...
- Redis:为什么您应该多缓存少查询(为什么使用redis做缓存而不是其他的消息队列入kafka)
-
还在一次又一次地调用相同的API吗?这不仅效率低下——而且成本高昂。性能缓慢、成本更高,用户体验更差。让我们停止这种做法——从这篇文章开始。:D首先您需要了解Redis,简单来说,它是一个超快速的内存...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (74)
- oracle批量插入数据 (65)
- oracle事务隔离级别 (59)
- oracle 空为0 (51)
- oracle主从同步 (56)
- oracle 乐观锁 (53)
- redis 命令 (83)
- php redis (97)
- redis 存储 (67)
- redis 锁 (74)
- 启动 redis (73)
- redis 时间 (60)
- redis 删除 (69)
- redis内存 (64)
- redis并发 (53)
- redis 主从 (71)
- redis 订阅 (51)
- redis 登录 (54)
- redis 面试 (58)
- 阿里 redis (59)
- redis 搭建 (53)
- redis的缓存 (55)
- lua redis (58)
- redis 连接池 (61)
- redis 限流 (51)