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

接口由40秒到200ms优化记录

标签：功耗   使用   初步   数据   产品   获取   入库   缓存   自带   

原文地址：https://www.cnblogs.com/nyatom/p/9366162.html