3 抢红包系统

我们还是按照我们分析问题的方法论开展

一 场景分析
我们分析的是集体活动的抢红包,比如春晚,大型活动红包,需要在网页操作的抢红包

抢红包的问题也是多个人抢资源的问题,可以和秒杀进行比对。但是也有很多不同的地方。

  1. 用户打开抢红包界面,注意是1亿人在短时间内打开
  2. 比如春晚的时候为了节目效果,会不定时的发送红包,这么大的用户量我们肯定要做防刷。那么每次发红包的时候怎么及时通知到客户手机,改变页面的状态
  3. 用户抢红包动作的瞬间爆发
  4. 锁的问题
  5. 不能太浪费服务器资源的问题(毕竟发红包也不是天天发,能省多少服务器尽量少用多少服务器)

二 思考解决方案

  1. 我们上面说的第一点,用户打开抢红包软件的时候。资源加载的问题和我们说的秒杀一样,能在CDN上加速的就放到CDN上。

  2. 对应我们上面说的第二点红包状态分发的问题。我们上面也说了,抢红包是短时间的高并发行为,我们不能为这一个行为花费大量的硬件资源。如果有这个条件,我们把代理做好加机器就可以了。基于这个思想我们在架构上就需要一些优化的想法了。
    我们知道当春晚的主持人在台上说3、2、1 我们发个大红包的时候,工作人员点击发放红包,只是一个状态的改变,我们把红包可抢的状态置为1,同时有多台机器和发红包这个动作的服务器保持连接状态,这些机器的红包状态也置为1.同时用户手机和这些机器保持连接,我们就可以把发红包这个动作快速的给到用户的手机。这个中间状态的机器分为几层要多少机器我们需要根据实际的用户体量计算。相当于一个多叉树的分发机制。如下图所示:
    在这里插入图片描述

  3. 上面的第三点说的是流量瞬间爆发的问题,有人会想到MQ去削峰。但是如果是一台机器几千万的流量同时涌入,服务器也会瞬间崩掉,这个时候我们也要多态机器去处理这些请求。我们需要去考虑需要多少台机器能承载这些流量,

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值