你知道公司年会抽奖系统是怎么实现的吗?

需求出现

年会将近,而年会抽奖环节必不可少,但是抽奖系统却还没有。所以某一天,PM走过来说:小伙,手头的需求修完成了吧!在年会开始之前必须做出一个抽 奖系统。这个系统很简单,后台可以设置总金额,然后每个用户可以获得的金额范围,金额派完则显示很遗憾没有中奖,还要设置抽奖活动时间。0?wx_fmt=png

抽奖系统业务分析图

需求分析

一看这东西,就觉得非常简单。最简单的一个方案,活动时间放在一个数据表,总金额和已经使用金额存放在一个表,已经派送的日志一个表。后台提供一个 接口,客户端手动点击按钮,则发送一个请求。账号体系直接使用微信的oauth,接口首先判断活动有没有开始,如果开始则随机一个金额,然后判断如果派送 该金额会不会超预算,如果不超预算,则调用微信的现金接口发放零钱。

0?wx_fmt=png

最原始的架构设计图

并发问题

这个简单方案存在一个致命的问题,就是并发下,可能导致超预算的问题。如果采用加锁的方式,面对1000多员工同时请求,系统100%瘫痪。(因为抽奖系统的服务器是最普通的1核1G 1M带宽的服务器)

0?wx_fmt=png

超预算问题触发情况

那么不加锁的情况,又能如何避免并发造成的派送超过预算的问题呢? 一个简单的办法,把分配派送金额的操作从并行变成串行。那么就需要异步的编程方法。最简单的处理方法,把任务写入mysql,然后启动一个独立的进程来一 个任务一个任务的串行处理。异步的话,客户端如何知道服务器已经处理了呢?最简单就是采用轮询的方法了,客户端每隔几秒就请求服务器一次。

0?wx_fmt=png

异步处理抽奖操作

性能问题

由于抽奖是短时间大量用户请求的,如果直接让请求落到mysql,类似DDOS攻击,一般的数据库是扛不住的。而redis是1种基于内存的高并发NoSQL,在很多公司广泛使用,由于其性能非常好,并且其丰富的数据接口完全可以胜任抽奖任务需求。

这个时候,你可能有这样的疑问,我们的系统设计是怎么样的呢?

  1. 抽奖系统相关配置存储在redis的一个key值,直接使用json格式

  2. 客户端请求的时候判断,时间是否在活动时间范围内

  3. 客户端请求如果时间在活动范围内,则把用户添加到一个redis集合,用于防止用户重复请求,只有第一次请求才会添加到集合后,再添加到一个redis列表。

  4. 后台一个独立的进程,从redis列表pop第一位用户,然后分配一个金额,然后把金额和用户信息压入另一个redis列表B,同时写入redis的hash结构,标示用户获得多少现金。一直循环该过程。

  5. 后台另一个独立的进程,从redis列表B pop第一位用户,然后调用发送现金接口,一直循环该过程。

  6. 客户端不停轮询获取用户金额的接口,该接口从哪个hash结构获取用户金额,然后没有数据,则告诉客户端若干秒后再次请求。

0?wx_fmt=png

最终架构图

前端优化

由于参与活动的人数较多,而且服务器是放在外网的,所以需要考虑带宽的问题。

1. 第一步,把静态资源放到cdn。

0?wx_fmt=png

静态资源cdn化

总结
  • 整套系统开发没有任何难度,唯一需要注意高并发下性能和数据问题。

  • 静态资源放到cdn,避免带宽成为瓶颈。

  • 把mysql操作变成redis操作,解决io问题

关于

书籍推荐请点击最下方的阅读原文!

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1按住上方的图片,在弹出的小框点击一下   “识别图中的二维码”,然后在新页面点击关注,然后有问题就可以留言提问了,也可以静静等待我们的新文章,就是这么任性。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值