分享一下我们的学习系统提交并发能力的实践步骤。

 

讨论范围：单企业独立部署系统，非saas产品。用户50万左右，单表数据不超1.5亿。

说到并发很多，很多人说我们千万上亿的量，使用了xx组件 xx缓存。很简单呀。

实际做下来是怎么用这些组件，怎么配合使用，保障了性能和高可用。

最终结果：jmeter集群压测可到达5000+。

 

考试系统有个特点，平时不用，集中考试的时候并发突出。所以同样1万的考试系统。比10万人的办公系统并发要求可能还高一些。

 

先介绍项目基础情况：

项目使用框架：

技术架构图

 

 

架构图简单说明：常规微服务架构。使用spingcloud、redis、kafka、mysql、mybatis.nacos

jdk版本开始使用jdk8.重构时更换为jdk17. mysql 升级为8, 这俩版本影响不大。

其他组件为了美化，测试场景会用到。

部署拓扑图：

部署说明：

4个主要服务（4个）部署3个节点，redis用cluster模式，mysql 3个库，测试时未开主从。

参考阿里云 ：4核16G机器5-6台。mysql 4核16G 3台。

优化流程：

一、先进行项目压测摸查项目基本情况

 

压测工具：jmeter

链路追踪：Skywalking

开发就可以学习jmeter，从登录到考试完整流程脚本不会很多。

重点：使用Skywalking、使用Skywalking、使用Skywalking。

 

二、根据压测 查看Skywalking中发现的问题。

 

这个说的简单，做起来就很难，这涉及到的修改其实是系统系统提高的最夯实的基础。

需要细心去看自己的项目，发现的问题去修改。排查是nginx端瓶颈、服务端瓶颈、数据库瓶颈。

我总结下我们项目修改的几个主要点：

1.一次sql关联表不能太多，针对压测发现复杂sql进行优化，优化后效果不好的，拆分成多次执行。如先查主要数据，次要字段再执行in查询（一般是分页的in的条数为10，不超过100）

此问题改的最多，大多开发不注意，导致sql偏复杂。

2.对在sql中进行了函数计算的去掉。

3.对group by后导致索引失效的sql优化调整。

4.对数据库最大的2-3个表，数据过亿的进行分区创建，分区的表不宜过多。

5.项目基础架构中统一使用的拦截器、过滤器要注意。

 

三：重复一二步骤，我们大概进行了3 4次回归。用时3-4周。

 

四：使用缓存和队列的场景。

 

对集中提交查询（考试一起进入）、集中提交（到时间统一交卷）请求的场景。

原则：对用户提交后直接看到结果，中间数据可以放缓存和队列，再进行数据库批量操作。

如提交试卷：针对提交时试卷成绩每人一条记录的结果，可以实时操作数据库。试题100道 200道可以缓存进行操作。

 

五：根据业务流程，把考试压力分摊到别的服务一部分。

 

过程中的一些压测的结果

 

 

结尾：最终并没什么高深的技术，还是同样的同事修改问题，修改逻辑，方法改变，达到系统性能翻倍的结果。

以上经过实践可满足同时1-2万人单场考试，系统压力最大在考试的前10秒，数据显示前6秒进了40%的人。

此次优化调整，对数据库表调整很小，主要是代码优化、逻辑流程优。

 

学习是一种态度，我们一直在路上。