接口由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());
}
}
}