一次高并发之后的追悔莫及

前言

18年7月的时候,在项目中写了一个考试的模块,流程大概是做一题,点击提交,后端接受答案并存储,最后点击交卷,后端算分并写入存储结果的数据库。写好之后,测试了一遍,没有逻辑上的Bug,交至测试部,由测试部的同事测试。过段时间,项目交付了。


但是,出问题了,测试部的同事没有做压力测试。


项目在第一次的使用中,大概有150人进行使用,由于考试之前答案基本都出来了,导致并发太高,代码扛不住了。此时写代码,根本没有想过性能问题,安全问题等,毕竟刚刚毕业。
出问题当天,飞到了长春改代码去了。
大佬带我飞过去的,到了酒店给我说了优化的思路。架构短时间之内基本不可能在改了,毕竟几天之后就是下一次考试。
也总结了一下,大概是这么几点:
1. 架构不合理,这个是我自己设计架构,毕竟需求就几句话,其他的自由发挥。
2. 代码写的质量实实在在不行,没注意过性能,安全问题,也没有考虑过并发能不能抗的住
3. 貌似服务器配置有些问题,大佬这个没和我说具体的问题,改了几个配置。

问题已经出来了,就得解决。因为时间紧急,所以代码框架就不动了,主要是第二个问题,优化代码,优化对数据库的操作。
1. 减少数据库的查询,这个项目中有封装好的接口,不过这个接口大家都不知道,大佬之前写的,里面的数据是走的缓存。
2. 增加缓存,其实之前我在代码流程中,有部分用到了缓存,封装了的几个函数,里面的数据基本是不变的,走的缓存。这次大佬让我将能走缓存的都走缓存,大佬说先这样做,后面改提交流程的时候你再改,让这次考试顺利完成
3. 优化代码,将不必要的操作去除,减少不比较的数据库操作。调用更多的api接口,舍弃自己写的重复的方法。

虽然最后在长春解决了问题,但是现场考试的时候,还是能明显感知页面的卡顿,但是还没有出现平台直接GG的现象。当然,甲方的白眼和语言攻击是少不了的。

回来之后着手开始对整个流程开始优化。
1. 原来的流程是所有的题目都是请求回来的,现在改为后台创建考试的时候,生成一个json文件。前台点击进入考试的时候,读取生成好的json文件。为了安全性问题,只有当考试已经开始,用户有权限,公开考试等情况下,才回去请求json文件。
2. 原来流程中用户提交一题,往后端发一次请求,现在改为将用户提交的答案存在本地,使用window.localStorage来存储答案以及其他信息,减少请求以及对数据库的操作。
3. 使用缓存存储在后端判断正确的时候的正确答案,之前是查数据库,获取数据,处理之后生成一个{id:answer}的键值对,现在讲这个键值对存入缓存中,减少数据库查询。用户交卷的时候,只需要查询一遍数据库获取正确答案,之后的其他用户在交卷的时候都读取缓存中的数据。

大概就是如此吧,毕竟过去好几个月了,记忆比较深刻就是这些了。

最后的最后,感谢大佬对我的栽培,原本是大佬一个人去就行了,然后跟领导说带上我,一直安慰我,说遇到这种事才正常,才学的多。感谢!

发表评论

电子邮件地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据