Skip to content

问题梳理

长耗时优化接口

gm_service工程

/station/stock/out_stock_sheet/submit/batch 批量出库

缺陷:
    1. 加锁和解锁慢
    2. 数据库操作, subtract_stock_by_out以及generate_by_sheet 慢
结论:
    出单数量多, 每次循环都要加锁和解锁, 以及更新数据库操作, 只能异步优化

Method: Get
请求:
    ---- params ----
    type                M       int             查询类型
    start               C       date            下单开始日期(type为1或者2)
    end                 C       date            下单结束日期(type为1或者2)
    time_config_id      C       str             运营周期id(type不等于1或者2)
    cycle_start_time    C       datetime        运营开始时间(type不等于1或者2)
    cycle_end_time      C       datetime        运营结束时间(type不等于1或者2)
    search_text         O       str             搜索字段
    deal                O       bool            0-任务处理, 1-业务处理
响应:
    code                M       int             0为成功, 其它为失败
    msg                 M       str             错误提示信息
    data                M       json            返回数据容器
    {
        task_url        C       str             任务结果返回地址(deal为0时候返回任务地址, 否则返回业务处理结果)
    }

/station/stock/check/batch 批量盘点

缺陷:
    1. spin_lock加锁spu时候慢
    2. stock_increase_no_stock 和 stock_loss_no_stock 循环插入报损报溢记录,  当spu多的时候就慢
    3. update_stock_out_nolock 循环更改库存, spu多的时候就慢
结论:
    1. spin_lock加锁可优化, 可以将每次加锁spu的三步操作数据库合并为一步
    2. 在mongo中没法在做报损报溢批量插入记录的同时去批量修改库存, 操作数据库部分没法优化, 改为异步优化

Method: Get
请求:
    ---- params ----
    stock_details       M       list            库存明细
    deal                O       bool            0-任务处理, 1-业务处理
响应:
    code                M       int             0为成功, 其它为失败
    msg                 M       str             错误提示信息
    data                M       json            返回数据容器
    {
        task_url        C       str             任务结果返回地址(deal为0时候返回任务地址, 否则返回业务处理结果)
    }

/station/stock/in_stock_sheet/download_template 下载导入模板

描述:
    排查了线上从1月23号到1月28号的日志, 最长耗时的也只是3s多, 暂时无需优化

/station/order/edit 订单修改

描述:
    1. 邮件和日志中暂时没有看到耗时时间长的订单, 现在只是邮件报的平均耗时长
    2. get和post在同一个接口, 有可能会造成邮件报平均耗时长
    3. 等邮件报耗时时间长的时候再具体定位优化