前言
最近接到个任务，业务场景是需要处理高并发。
原谅我第一时间想到的居然是前段时间阮一峰的博客系统遭到了DDoS攻击，因为在我的理解中，它们的原理是想通的，都是服务器在一定时间内无法处理所有的并行任务，导致部分请求异常，甚至会像阮一峰的博客一样崩溃。
之前不太有接触过高并发的机会，所以并没有什么实际经验，倒是之前做的项目中有秒杀功能的实现做过一定的处理，当时的处理就是多利用缓存进行优化和减少一些没必要的后端请求，但是因为是创业公司，所以并没有多少过多的流量，即便是秒杀，所以也没有进行更进一步的优化了，业务需求不需要，自己也没有过多去思考这个问题了。
其实刚开始我还是有些想法，利用HTTP头部，强缓存（cache-control）、协商缓存（last-modified和Etag）、开启HTTP2，尤其是HTTP2应该能将性能提升不少吧，但是这些方案大多都需要后端支持，那么前端能做什么呢，倒是还真没好好思考和总结一下。
理解
架构搭建之前首先要把需求理解透彻，所以去谷歌搜索了一波，首先看几个名词：
- QPS：每秒钟请求或者查询的数量，在互联网领域，指每秒响应请求数(指HTTP请求)
- 吞吐量：单位时间内处理的请求数量(通常由QPS与并发数决定)
- 响应时间：从请求发出到收到响应花费的时间，例如系统处理一个HTTP请求需要100ms，这个100ms就是系统的响应时间
- PV：综合浏览量(Page View)，即页面浏览量或者点击量，一个访客在24小时内访问的页面数量，同一个人浏览你的网站同一页面，只记作一次PV
- UV：独立访问(UniQue Visitor)，即一定时间范围内相同访客多次访问网站，只计算为1个独立访客
- 带宽：计算带宽大小需关注两个指标，峰值流量和页面的平均大小
再看几张图：
正常访问：
高并发：
客户端精简与拦截：
那么怎么浅显的解释下高并发呢？把服务器比作水箱，水箱与外界连接换水有三根水管，正常情况下都能正常进行换水，但是突然一段时间大量的水需要流通，水管的压力就承受不了了。再简单点：洪涝灾害、早晚高峰、中午12点的大学食堂，大概都是这个原理吧。这些现实问题怎么解决的呢，高并发是不是也可以借鉴一下呢？
- 洪涝灾害：修固堤岸（增强服务器性能）
- 早晚高峰：多选择其他路线（分流，和分配服务器线路），不是一定需要就避开早晚高峰（减少客户端请求）
- 中午12点的大学食堂：学校多开几个食堂（静态资源与后端api分到不同服务器）
回到高并发的问题上，我认为解决方案主要有这些：
- 静态资源合并压缩
- 减少或合并HTTP请求（需权衡，不能为了减少而减少）
- 使用CDN，分散服务器压力
- 利用缓存过滤请求
后来发现如果要把优化做到很好，雅虎35条军规中很多条对解决高并发也都是有效的。
回到业务
回到业务上，本次业务是助力免单。设计图没有几张，担心涉及商业信息就不放图了，因为要求是多页面，我将业务分成三个页面：
- 首页，查看活动信息页
- 查看自己活动进程页，包括活动结束，开始活动，活动进行中和助力失败几个状态
- 帮助他人助力页，包括帮他助力和自己也要助力两个状态
解决方案
利用缓存存放数据
简单分析了一下，需要的数据有：
- {
- // 这个活动的id，防
