记一次高并发应用的优化实践

项目背景

大家好，笔者接手的项目是一个给学生使用的在线考试测评系统，整个系统部署在阿里云上，配置情况为：一台RDS数据库+二台ECS服务提供题库服务+二台ECS服务提供WEB服务+一台SLB负载均衡。应用接手之初，每天中午和晚上两个高峰，并发用户数在1500左右。随着应用的推广，用户并发量上升到2000左右，用户访问系统就开始卡死，没有反应了，系统瘫痪了。

优化过程

出现问题后，从以下几个方面着手优化应用：1）访问入口负载均衡；2）WEB服务器；3）数据库性能；4）业务逻辑优化

SLB优化

查看了SLB的带宽和用户并发数，原来的SLB购买的是固定带宽10Mbps，当用户并发数超过1500以后，带宽就占用满了。
原来购买的是固定带宽，只有2种升配方式，一种直接将固定带宽升配到最大值；另一种就是在用户高峰期进行短时升配，按量付费。我选择了第二种。

WEB服务器

两台ECS服务器的配置是4核8G的配置，每台只部署了一个TOMCAT实例，查看了ECS的CPU和内存使用情况，CPU只用到了15%。WEB服务器的使用率太低了。决定ECS服务器上各部署2个TOMCAT实例，在ECS上做二级的负载均衡。

数据库RDS

查看了数据库的CPU和内存使用情况。高并发时段，数据库的CPU一直在100%水平，内存使用相对平稳在80%。说明数据库是最大的瓶颈，导致应用卡死。
1）慢SQL优化
RDS的性能诊断里，可以抓取出大量慢SQL，需要进行SQL优化。阿里云的RDS提供完善的诊断工具。
2）高频的读写操作
RDS支持读写分离，对Mysql数据库申请一个只读实例，该实例是按量付费的，我们将查询和读入进行分离。
阿里云只需要申请一个只读实例，对用户而言常规实例与只读实例间数据的同步和一致性是完全透明的。但是我们仍然需要修改应用，将查询修改到只读实例上。
3）RDS数据库规格升配
原来的数据库8核32G的，直接升配到16核64G。

业务逻辑优化

在线考试测评系统的业务，每次的测评都是实时动态组卷生成试卷的。高并发的情况下，实时组卷需要进行多次的IO操作，取读全量试题，动态组卷，读取试卷，提交答案，试卷分析。
1）进行预组卷
将实时动态组卷的大量IO给前置，预先批量组卷，放在资源池里。每次测评时从试卷池抽取试卷即可
2）使用Redis
用户提交答案，以及后续的试卷分析。我们不直接提交到数据库，而是先提交到Redis，然后数据分析直接在Redis上进行，Redis再定期将数据刷新到数据库。这样也能减轻数据库的IO压力。

优化效果

经过上述的整体优化，现在系统已经可以承受5000的用户并发数。

点击以下链接有彩蛋噢
https://promotion.aliyun.com/ntms/yunparter/invite.html?userCode=9asb6duq