高并发经常会发生在有大活跃用户量来访问网站的某个点，例如用户高聚集的业务场景中，如：抢购，促销等。为了让用户流畅的访问网站，来根据自己的业务设计适合系统的处理方案。
//对于APP网站首页数据，通常是有APP请求服务端数据在本机进行绘制。APP越少的请求服务端的，就会减少服务器压力：资源和带宽。
1.服务端给APP下发的数据越少，减少无用字段的下发。就是APP需要什么，服务端下发什么。
2.APP每次请求服务端数据，服务端下发最新数据和数据版本号，APP可以缓存到本地，每次接口请求数据的时候，上传当前缓存数据的版本号，服务端也计算出最新数据的版本号，进行对比，如果版本号相同不在下发数据，APP直接调取本地数据，反之，服务端下发最新数据和数据版本好给APP。
3.服务端架构方面的设计，不在由APP请求接口时被动redis 数据或者是不做缓存操作。 而是服务端主动调取mysql数据，刷入redis，APP请求接口只从redis 读取数据
下面是为Api->app调取数据设计的服务端的架构简图，也是目前我在项目中使用的。
逻辑方面：
有cron进行主动请求mysql数据，进行刷新redis数据，app通过api接口请求redis数据。
因为cron是定时任务脚本，所以主动请求时间不能太短，频繁请求mysql数据，这样就会给mysql资源造成压力。最好是在5-10分钟之内。但是这样就有一个问题数据不同步，如后端更新数据到mysql，cron要5-10分钟才能主动请求刷新redis.稳定和性能上都比较好些，所以重构的时候采取了这样的方案。
这样就设计的刷新缓存的策略的问题
1.主动刷新
1）后台更新时，删除缓存，主动触发cron脚本，刷新缓存
这样先删除缓存，再写入。在用户请求是会出现访问不到数据。会影响用户体验。
2）后台更新时，主动触发cron脚本，刷新缓存
对于这样，后台大量数据更新，可能会多次对一个key写入redis,会想redis刷入不确定的数据，影响数据显示的正确性
3）后台更新时，主动触发cron脚本，生成数据版本号，版本号作为key保存数据,存入版本号栈，最上面是最新数据的版本号，最下面是原始数据的版本号，当APP请求时，app上传的版本号和原始数据版本号，如果相同不下发数据，不同的话，弹出栈顶层版本号，下发最新数据，删除旧版本号数据（会造成垃圾数据的积累），版本号栈重写。
为啥没采用呢，因为当时没有想到。。。。。。。。。。。
4）由cron脚本主动请求数据库，刷新数据，频率不能太高。
数据有一定的延迟性
2.被动刷新
把刷新数据的任务交给app请求，如果app请求时redis内没有数据，则请求各个接口调取数据库数据，下发数据和版本号，刷新redis缓存。
当大量访问时，会产生并发的访问，造成阻塞。
app访问整体简图