方案在性能优化中的重要性1

一时失言乱红尘 2023-01-16 14:23 181阅读 0赞

有一次领导说考试系统很慢让优化一下，不想代码改动量太大，这就是现实。经过与开发人员沟通，并查看写的代码；发现该系统实际业务有好多加以加载缓存，而开发人员却一直说无法加缓存;因为他们认为根据他们的查询条件，定位出来的数据都是一条。所以加缓存无意义。这就是问题所以，可能我说的大家没听明白，下面示例需大家细心观察。

![2021042610203761.png][]

![202104261021568.png][]

![20210426102259453.png][]

通过上面发现其实很多东西是有共性的；

改造 方案：

一、把所有这样类似的全部在持久层直接按examId查询；（大家可能会考虑这样加载的数据多了不会慢吗，怎么反而会提高性能呢）

首先把examId做成索引，虽然一次加载的数据多，会造成单次数据的访问压力加大。但也为数据做缓存做下铺垫。

二、针对所有这类改造完的接口做缓存，这样提高缓存的有效性

因为都是根据examId做的缓存，考试的时候根据考试编号（examId）查询这类信息的人会很多。相信到这一步大家就已经明白了，不明白的小伙伴继续看下面

三、针对各业务需要过滤数据的在业务层处理

过去dao层

query(String examId,String stuid);

过去service层

query(String examId,String stuid)\{

dao.query(examId,stuid);

改造后

dao层

@Cacheable(value="mgxx:student",key="targetClass +':'+methodName +':'+ #examId")
    query(String examId);

service层

query(String examId,String stuid){
        List<ExamEntity> examEntityList=dao.query(examId);
        List<ExamEntity> filter= examEntityList.stream()
                .filter(exam -> exam.getStuid()==stuid)
                .collect(Collectors.toList());
    }

以上全是伪代码；但确实是真实项目遇到的。相信走看到这一步的小伙伴应该已经明白了。目的就是为了让缓存启作用。服务的整体吞吐，由过去的 120直接到2000

[2021042610203761.png]: /images/20221022/3aa1d893958c4351bd78a5f48c08b422.png
[202104261021568.png]: /images/20221022/778572ddc87e40f89c7ee213574c3ed3.png
[20210426102259453.png]: /images/20221022/21bf0cc6e00f48d5aa1ecfdea258152e.png