秒杀场景实践之抢红包 —— 常用解决方案
秒杀场景实践之抢红包常用解决方案
文章地址: https://blog.piaoruiqing.com/blog/2019/09/01/秒杀场景实践之抢红包一/
前言
秒杀场景在生活中几乎随处可见, 不论是商品抢购、春运抢票还是一个随处可见的红包, 都会涉及到秒杀的场景. 在面试中, 秒杀业务的设计也成为热门题目为面试官和应聘者津津乐道.
接下来, 本文将针对秒杀场景中的抢红包实现方案进行分享, 包括红包业务常见的实现方案, 瓶颈及优化.
分析
场景
红包的应用场景有很多, 如随机红包、定额红包等, 甚至还有结合其他促销业务的红包变种如抢购物津贴等. 但从技术的角度来看, 不论玩法有多少变化, 其核心都是相似的:
- 稳定: 扛得住突发的大流量, 确保红包都能成功派发.
- 准确: 数据一定要正确, 不能出现超额派发的情况.
业务
抢红包可能会由于业务需求不同而产生很多变种, 设计上要足够抽象, 不能为了抢现金红包和抢购物津贴红包写多份相似的代码. 抢到红包的后置操作可以作为消息, 由不同的业务模块自行处理.
技术
抢红包核心业务不复杂, 其关键点在于应对高并发、资源争用等.
-
高并发: 异步、横向扩展负载均衡、限流等.
-
读多写少: 缓存.
-
资源争用: 原子操作, 缓存或数据库等层面可进行控制. 如使用Lua脚本进行减库存操作.
方案一 —— 预分配
适用场景
红包数量相对合理, 很少产生库存剩余的情况、用户量级不大的情况.
- 优势: 实现简单、配合缓存很容易应对高并发
- 不足: 频繁发放较多数量大的红包会导致一次性写入大量分配记录, 如果领取的人不多, 会产生很多无效数据.
简要描述
预分配是在发放红包时, 根据红包总额和数量、按照既定算法进行分配, 提前创建好全部的红包分配记录. 领取时只是将红包分配记录进行更新.
比较适合系统发放的红包(面向某一标签的全部用户群体, 发出的红包基本会被领取完), 不适合用户群组红包(无法控制领取红包人数, 当红包个数远大于群组人数的情况下, 无效数据比较多, 比如在一个10人群组发放一个数量为1000的红包).