接口由40秒到200ms优化记录
场景还原
一个业务逻辑较为复杂的业务,涉及到n次遍历,其中有循环查询/更新数据库,事务的管理,加上一些业务逻辑的计算.最初的接口,纯粹按照产品提供的相关业务逻辑,单纯的编码,耗时较长,近40秒的处理时间
解决思路
碰到这种涉及到数据库相关操作的接口,首先想到的是降低与数据库间的交互,优先考虑将条件类的数据映射关系放在缓存中;其次,理解业务,处理数据写操作之间的对应关系,尽量将循环写操作调整为单条写操作;最后,理清整体业务逻辑,将数据库交互时的逻辑在Java代码中处理,再根据最终结果,统一入库(ps:本次业务场景下可用,具体情况再另说)
案例引入
业务:
引入大家熟悉的打卡考勤做案例来分析,考勤组人员的增删,这里涉及到几层关系:
1.考勤组--对应员工总数
2.员工--考勤组
3.员工--旧考勤组,员工--新考勤组
简单理解:n个员工,一个新的考勤组id. --> n个员工对应的考勤组变更为新的考勤组, 可能n个旧考勤组对应的员工总数减m个, 新的考勤组对应的员工总数加n个.
这里的难点在于 n个员工可能对应 f (f <= n) 个旧考勤组, f个旧考勤组具体根据对应的需变更员工数调整所属总员工数.
初步设计
1.遍历所有要修改的员工
2.得到具体的一个员工,获取其旧考勤组信息
3.每次循环,对应的旧考勤组所属员工总数减一,更新员工信息(设置所属考勤组为新考勤组)
4.新考勤组所属员工总数加n
计算功耗, 1次Java循环,n次查询,n * 2次更新
优化过程
1.将员工--考勤组的映射关系存入缓存,并在Java遍历中更新value,留后续操作使用
2.将考勤组--所属员工总数的映射关系存入缓存,并在Java遍历中++/--value
3.员工的批量update,使用mybatis的foreach配合多参数的用法
最终,1次Java循环,f+1次更新
速度立即降到200ms的标准接口数据返回时间.
局部代码:
// mybatis多参数配合遍历的用法 --> Mapper接口 Integer updateGroupIdForPersons(@Param("ids")List<Integer> ids,@Param("groupId")Integer groupId); // Mapper.xml <update id="updateGroupIdForPersons"> UPDATE person SET group_id = #{groupId} WHERE person_id IN <foreach collection="ids" item="personId" open="(" separator="," close=")"> #{personId} </foreach> </update> // 缓存采用的是 ConcurrentHashMap 不做赘述 配合SpringBoot自带的定时作业实现 /** * 启动一秒开启,之后每十分钟一次
* 注意,此处已将缓存逻辑整合到具体代码,所以可设为十分钟一次查库更新 */ @Scheduled(initialDelay=1000, fixedRate=600000) public void cachePersonsGroupsUpdateMap(){ List<Person> people = personMapper.queryAllPersons(); for (Person person : people) { if (person.getGroupId() != null) { PersonsGroupsUpdateMap.put(person.getPersonId(),person.getGroupId()); } } }