我们还是按照我们分析问题的方法论开展
一 场景分析
我们分析的是集体活动的抢红包，比如春晚，大型活动红包，需要在网页操作的抢红包
抢红包的问题也是多个人抢资源的问题，可以和秒杀进行比对。但是也有很多不同的地方。
- 用户打开抢红包界面，注意是1亿人在短时间内打开
- 比如春晚的时候为了节目效果，会不定时的发送红包，这么大的用户量我们肯定要做防刷。那么每次发红包的时候怎么及时通知到客户手机，改变页面的状态
- 用户抢红包动作的瞬间爆发
- 锁的问题
- 不能太浪费服务器资源的问题(毕竟发红包也不是天天发，能省多少服务器尽量少用多少服务器)
二 思考解决方案
- 我们上面说的第一点，用户打开抢红包软件的时候。资源加载的问题和我们说的秒杀一样，能在CDN上加速的就放到CDN上。
- 对应我们上面说的第二点红包状态分发的问题。我们上面也说了，抢红包是短时间的高并发行为，我们不能为这一个行为花费大量的硬件资源。如果有这个条件，我们把代理做好加机器就可以了。基于这个思想我们在架构上就需要一些优化的想法了。
我们知道当春晚的主持人在台上说3、2、1 我们发个大红包的时候，工作人员点击发放红包，只是一个状态的改变，我们把红包可抢的状态置为1，同时有多台机器和发红包这个动作的服务器保持连接状态，这些机器的红包状态也置为1.同时用户手机和这些机器保持连接，我们就可以把发红包这个动作快速的给到用户的手机。这个中间状态的机器分为几层要多少机器我们需要根据实际的用户体量计算。相当于一个多叉树的分发机制。如下图所示:
- 上面的第三点说的是流量瞬间爆发的问题，有人会想到MQ去削峰。但是如果是一台机器几千万的流量同时涌入，服务器也会瞬间崩掉，这个时候我们也要多态机器去处理这些请求。我们需要去考虑需要多少台机器能承载这些流量，在开发完成的时候还需要做压测。计算好这些，我们还要考虑代理服务器能不能承载的问题，代理服务器的多活问题(一般nginx+keepalive)，如果是独立的机房部署用LVS(四层代理，通过修改局域网的协议包，实现转发，性能更好)是不是更好的选择，如果公司不差钱，用H5(银行喜欢用这个)是不是也可以，这些就涉及到技术选型的问题了.如果这个不能保障的时候，是不是需要在外面还套一层DNS轮询。基本上加上DNS轮询后面再转发到多态保活的代理服务器，多大的流量都能承载了。
我们继续讲流量通过DNS和代理服务器之后的业务流程。我们知道1亿人抢几百万个红包必然很多人抢不到，我们在上一个话题中提到的可以通过不加锁的递增方案把已经不可能买到商品的人过滤掉大部分，我们在这里为了节约服务器资源也可以采用这个方案。
我们继续考虑节约服务器资源的问题，后面进入到的用户也是一个可观的流量，这个时候我们就要考虑削峰的问题了，加上MQ，拉平流量峰值，MQ的消费端去处理相关的业务。这个时候我们又可以节约服务器的资源。
继续优化我们的设计。 我们知道数学计算是非常消耗CPU的一件事，我们在计算每个人能抢到多少钱的时候就是消耗CPU的一个动作，可以考虑把相关的计算放到CPU性能好的机器去部署，其他的普通机器又能节约很多，为老板省钱也是架构师的一个职责。
后面的业务就是转账等等一系列的业务流程我们还是要对服务进行水平拆分，但是经过我们前面一系列的骚操作以后，已经把这块业务的并发打下来了，做正常的分库分表相关的设计就可以了。如下图所示:
- 上面说到的第四点锁的问题。为了红包不被多抢，我们在进入到领红包这个环节已经是用户抢红包的哦动作进入到mq之后的事情了，这个时候我们可以采用分布式锁(因为涉及到钱的问题，我们要保障分布式锁的高可用，比如我们用redis做分布式锁，假如redis挂了的问题)，也可以采用CAS锁，这个要安全点毕竟涉及到钱(CAS最大的问题是ABA的问题，如果并发非常大的情况下不建议使用，他会一直ABA卡在那里)。因为我们经过了MQ并发已经被打下来了，用这个安全性会更高点。
- 上面说到的第五点，我们在前面阐述中已经考虑到了，不再细说。 我们还要注意我们的设计中MQ的高可用，单台MQ如果承载太多的请求信息会造成消息积压的问题，我们需要考虑会有多少消息积压的问题，要不要MQ要做分而治之的方案。
- 通过以上的阐述，仔细思考过的朋友们可能意识到，我们在做架构设计的时候需要考虑我们的业务场景，用户行为分析，业务场景中会有哪些操作，每个操作会遇到哪些问题。这个是我们做架构设计的普遍的方法论。如果我们能把这些做好，做技术选型的时候，即时我们对相关的技术没有深入的了解也可以通过查阅资料去了解。但是解决问题的思路是不变的
