<返回更多

秒杀场景实践之抢红包

2019-09-03    
加入收藏
秒杀场景实践之抢红包

 

前言

秒杀场景在生活中几乎随处可见, 不论是商品抢购、春运抢票还是一个随处可见的红包, 都会涉及到秒杀的场景. 在面试中, 秒杀业务的设计也成为热门题目为面试官和应聘者津津乐道.

接下来, 本文将针对秒杀场景中的抢红包实现方案进行分享, 包括红包业务常见的实现方案, 瓶颈及优化.

分析

场景

红包的应用场景有很多, 如随机红包、定额红包等, 甚至还有结合其他促销业务的红包变种如抢购物津贴等. 但从技术的角度来看, 不论玩法有多少变化, 其核心都是相似的:

业务

抢红包可能会由于业务需求不同而产生很多变种, 设计上要足够抽象, 不能为了抢现金红包和抢购物津贴红包写多份相似的代码. 抢到红包的后置操作可以作为消息, 由不同的业务模块自行处理.

技术

抢红包核心业务不复杂, 其关键点在于应对高并发、资源争用等.

方案一 —— 预分配

适用场景

红包数量相对合理, 很少产生库存剩余的情况、用户量级不大的情况.

简要描述

预分配是在发放红包时, 根据红包总额和数量、按照既定算法进行分配, 提前创建好全部的红包分配记录. 领取时只是将红包分配记录进行更新.

比较适合系统发放的红包(面向某一标签的全部用户群体, 发出的红包基本会被领取完), 不适合用户群组红包(无法控制领取红包人数, 当红包个数远大于群组人数的情况下, 无效数据比较多, 比如在一个10人群组发放一个数量为1000的红包).

实现细节

秒杀场景实践之抢红包

 

流程

-- 此处划重点 ( ̄▽ ̄)"
UPDATE IGNORE record SET user_id = {userId}, gmt_receive = UNIX_TIMESTAMP() WHERE red_envelop_id = 1 AND user_id < 0 LIMIT 1;
-- red_envelop_id + user_id 有唯一约束

红包发放记录

ID 总金额 数量 ... 1 100 3 ... 红包分配记录

unique: 红包ID+领取用户ID

秒杀场景实践之抢红包

 

方案二 —— 实时分配

适用场景

领取人数无法估计、频发退款, 如群组红包(经常发生剩余退款)

实现细节

秒杀场景实践之抢红包

 

流程

红包发放记录

秒杀场景实践之抢红包

 

unique: 红包ID+领取用户ID

细节及优化

结语

秒杀场景其特点是高并发、读多写少、资源争用, 每一个点都需要根据其业务场景选择适合的解决方案, 如使用缓存解决频繁读取的问题、使用队列解决数据库性能瓶颈等.

对于抢红包业务来说, 预分配和实时分配都是行之有效的方案, 各有优劣, 具体选择哪种, 还是要看业务需求.

如果这篇文章对您有帮助,请点个赞吧 ( ̄▽ ̄)"

原文:https://blog.piaoruiqing.com/blog

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>