Java教程

记一次首页并发白屏优化过程

本文主要是介绍记一次首页并发白屏优化过程,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

      一个服务于近300家500强企业的企业培训软件, app应用的首页居然反复出现白屏,请求超时,负载过高,挤占其他业务服务器资源,最终整个程序无响应的现象,更难想象压测 5线程时, tps 仅有 20 , 诺大的一个公司,居然这么少的处理效率,平时赶上X踏,X耀,X金这种动则好几万人的集团公司有在线抽奖,课程学习,以及签到打卡的活动时,问题频出,虽然刚签完协议,离职也还有几天,上头又将这个烫手山芋交给我处理,但本着:在其职,谋其位,尽其力,担其责 的原则 ,还是好好的处理此事。

     首页之所以加载慢,来自于大量的流程处理,其中穿插各业务的的特殊流程,涉及到redis,mongo,solr等等,整个链路非常长,举个例子,首页可以配置1个显示方案,方案都有对应的可见人员的范围,这些方案下配置各个业务的功能跳转,功能本身是有权限的,功能也有自己特殊的逻辑,如是否VIP,如可见人员等等,举例如下图(不能说和B站像似,只能说一摸一样),整个首页的内容称之为一套显示方案,这个方案至少由5部分组成, 1.频道页签,2快捷图片,3快捷图标,4内容面板,5底部运营, 其中会涉及到多个频道,多个内容,而频道,内容都会有对应的可见范围,也就是说,即使A 和B 用的是同一套配置方案(若干频道,内容全部相同),但是只要其中某个频道,某个功能的可见范围和权限不同,那么最终 A,B 两人的界面就会不一样,如A多几个模块,B少一些模块,那如果配置方案便不相同,那A,B的界面可能完全天差地别,这也是啥叫互联网杀熟, 说白了就是不同的账号,登录同一个app,显示的东西,或者搜索同一个东西,结果不一样(淘宝:你是在说我吗?杀熟我都是老手了)

 

 了解完这一套流程,然后去分析内部的实现,如右上图, 白色部分是原逻辑的简易流程图,即使已过滤掉了大量的链路,仍可预见存在诸多问题,存在优化空间,总所周知,优化来源于三大方向:

设计上:不同的产品一年又一年无脑堆功能到首页,各种乱七八糟的特殊要求,并且态度强硬, 不同的研发一茬接着一茬同步实现,嗯,相信后人的智慧

硬件资源:本不富裕的日子肯定不能雪上加霜, 纵然是可怜巴巴的服务器亦如此,坚信只要销售强,再烂的产品都能推销出去

实现上(代码层面,仓储层面):只能苦一苦研发,代码是他们写的,问题都是他们的,纵然是流水的研发,铁打的bug,后人也得啃下来

    啃一啃,也没什么,分析如配置内容,以及实体这一块,如果id相同,那么计算的结果便是相同的,可以拆分出来做一个缓存,第二部分功能的跳转,部分涉及权限,完全可以将其剔除,等到跳转后,业务自行判断,对首页的主流程进行解耦,但是这个方案直接被否决,虽然是少数功能会有权限验证,但是用户就是要直接过滤,能显示但是跳转后却提示无权限,会有意见,ok,若如此也不是不行,将权限这一块的功能和不需要权限的功能进行拆分,剥离需要摆人员权限的功能,单独判断,再剩下的大部分功能进行一个缓存处理,这样就会造成一个排序问题,所以再组装拿到最终结果之后,再进行一个排序,保证进入的功能和出去的内容顺序一致,最后再加个分布式事务锁,短时间内也就只能处理成这样, 运行多年且成型的框架没有深耕最好还是慎重调整结构,很可能小毛病重构到 ICU。嗯嗯,相信后人的智慧。

      简单的 redis 拆分 +分布式锁 ,tps 从20 直接到 120 ,纵使 shit 山代码,简单的优化一下,也能提升不少,如果从设计上一开始就规避这种对策功能,只管实现的要求,tps 处理还能更高, 这么简单的道理为啥不懂? 无非是快速迭代,快餐思想,为追求结果只图快,体验如何,马马虎虎,差强人意就行,即使某天有故障,先临时扩容再说,上面还有ppt大侠,张嘴闭嘴就是系统垃圾,需要重构,如何如何好,然后一计算成本,哈哈,还是保持现状,得过且过!    

                 优化后                   

 

这篇关于记一次首页并发白屏优化过程的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!