首页 > 代码库 > 网站的优化----首页优化---app调取服务端数据
网站的优化----首页优化---app调取服务端数据
高并发经常会发生在有大活跃用户量来访问网站的某个点,例如用户高聚集的业务场景中,如:抢购,促销等。为了让用户流畅的访问网站,来根据自己的业务设计适合系统的处理方案。
//对于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访问整体简图
网站的优化----首页优化---app调取服务端数据